jueves, 20 de octubre de 2011

Redistribución de protocolos de enrutamineto

Antes que nada quiero dar las gracias al Sr. Oscar Gerometta que nos aporta esta grandiosa informacion desde su blog

Para que dos dispositivos (routers o switches capa 3) intercambien información de enrutamiento es preciso, en principio, que ambos dispositivos utilicen el mismo protocolo, sea RIP, EIGRP, OSPF, BGP, etc. Diferentes protocolos de enrutamiento, o protocolos configurados de diferente forma (p.e. diferente sistema autónomo en EIGRP) no intercambian información.
Sin embargo, cuando un dispositivo aprende información de enrutamiento a partir de diferentes fuentes (p.e. rutas estáticas o a través de diferentes protocolos) Cisco IOS permite que la información aprendida por una fuente sea publicada hacia otros dispositivos utilizando un protocolo diferente. Por ejemplo, que una ruta aprendida a través de RIP sea publicada hacia otros dispositivos utilizando OSPF.

Esto es lo que se denomina "Redistribución" de rutas. Utilizar un protocolo de enrutamiento para publicar rutas que son aprendidas a través de otro medio (otro protocolo, rutas estáticas o directamente conectadas).
El mecanismo de redistribución es propietario de Cisco IOS. Este mecanismo establece algunas reglas:

*La ruta a redistribuir debe estar presenta en la tabla de enrutamiento.

*No se redistribuyen rutas que están presentes en tablas topológicas de los protocolos pero no en la tabla de enrutamiento.

*La ruta redistribuida será recibida por el dispositivo vecino con la métrica raíz del protocolo en el que se redistribuye.

¿Para qué se utiliza?

En principio es deseable que una red utilice un único protocolo de enrutamiento.
Sin embargo, en algunos casos puede requerirse el uso de redistribución: fusiones de empresas, diferentes departamentos de una misma empresa administrados por diferentes equipos de personal, entornos multi-vendor, migraciones, etc.
Al momento de abordar una redistribución de rutas se deben tener presentes algunos aspectos particulares del enrutamiento: las diferentes métricas, las distancias administrativas de cada protocolo, las capacidades de enrutamiento classful y classless, y la topología de la red.


Las métricas
Cada protocolo de enrutamiento utiliza una métrica diferente. Esto hace que al redistribuir rutas se pierda la métrica original del protocolo y sea redefinida en los términos del nuevo protocolo. Por ejemplo, si se redistribuye una ruta OSPF con una métrica de 1642 en RIP, RIP le asignará una métrica en cantidad de saltos (entre 1 y 15).
La métrica con la que un protocolo recibe las rutas aprendidas por otro, se denomina métrica raíz.
Cada protocolo utiliza una métrica raíz por defecto:

RIP - métrica raíz por defecto: infinito.
EIGRP - métrica raíz por defecto: infinito.
OSPF - métrica raíz por defecto: 20.

Esta mética raíz por defecto también puede ser modificada utilizando el comando default metric.


Los comandos básicos
Al configurar redistribución debemos indicar al protocolo qué información de enrutamiento redistribuir, y con qué métrica deseamos se redistribuyan esas rutas. Si no indicamos nada, las rutas son redistribuidas con la métrica por defecto.


Router(config)#router rip
Router(config-router)#network 129.100.0.0
Router(config-router)#redistribute ospf 1 metric 2


En este ejemplo indicamos a RIP que redistribuya la información de enrutamiento aprendida a través del proceso 1 de OSPF que se encuentra en la tabla de enrutamiento, con una métrica de 2 saltos.


Redistribución en EIGRP
Al redistribuir información de enrutamiento utilizando EIGRP, es preciso tener presente que la métrica por defecto es infinito. Por lo tanto, si no especificamos métrica, las rutas redistribuidas no aparecerán en la tabla de enrutamiento del dispositivo vecino.
Por otra parte, al definir la métrica es preciso indicar: bandwidth, delay, reliability, load y MTU.
Un ejemplo:


Router(config)#router eigrp 100
Router(config-router)#redistribute static
Router(config-router)#redistribute rip
Router(config-router)#default-metric 10000 100 255 1 1500


Redistribución en OSPF
La métrica por defecto que utiliza OSPF es de 20, por lo que no exige que especifiquemos una métrica para que la ruta sea aprendida por los dispositivos adyacentes. Sin embargo, cuando hay múltiples subredes de una misma red y se desea publicar rutas para cada subred, es preciso indicarlo pues de lo contrario OSPF sumarizará todas las subredes al límite de la clase y publicará una sola ruta.
Un ejemplo:


Router(config)#router ospf 1
Router(config-router)#redistribute static metric 200 subnets
Router(config-router)#redistribute eigrp 100 metric 500 subnets


Redistribución en RIP
Como en EIGRP, al redistribuir en RIP el protocolo utiliza una métrica por defecto de infinito, con lo que es necesario especificar una métrica diferente para que el router vecino incorpore la información de enrutamiento en su tabla.
Un ejemplo:


Router(config)#router rip
Router(config-router)#redistribute static metric 1
Router(config-router)#redistribute ospf 1 metric 2



miércoles, 19 de octubre de 2011

Encapsulacion PPP con autenticacion PAP&CHAP...y SSH



Merida#sh running-config
!
hostname Merida
!
username Maracaibo password 0 ciscochap
username Margarita password 0 ciscopap
username martin privilege 15 password 0 ciscossh
!
ip domain-name ppp.con.ve
!
ip ssh time-out 15
!
interface Serial1/0
description Conexion serial al Margarita
ip address 192.168.0.1 255.255.255.252
encapsulation ppp
serial restart-delay 0
ppp authentication pap
ppp pap sent-username Merida password 0 ciscopap
!
interface Serial1/1
description Conexion serial a Maracaibo
ip address 192.168.1.1 255.255.255.252
encapsulation ppp
serial restart-delay 0
clock rate 56000
ppp authentication chap
!
line vty 0 4
login local
transport input ssh
line vty 5 15
login local
transport input ssh


***configuracion SSH
Merida(config)#ip domain-name ppp.con.ve
Merida(config)#crypto key generate rsa
The name for the keys will be: Merida.ppp.con.ve
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 1024
Generating RSA keys ...
[OK]
Merida(config)#ip ssh time-out 15
Merida(config)#ip ssh authentication-retries 3
Merida(config)#username martin privilege 15 password ciscossh
Merida(config)#line vty 0 15
Merida(config-line)#transport input ssh
Merida(config-line)#login local

____________________________________________________________________________

Margarita#sh running-config
!
hostname Margarita
!
username Merida password 0 ciscopap
!
interface Serial1/0
description Conexion serial a Merida
ip address 192.168.0.2 255.255.255.252
encapsulation ppp
serial restart-delay 0
clock rate 64000
ppp authentication pap
ppp pap sent-username Margarita password 0 ciscopap

____________________________________________________________________________

Maracaibo#sh running-config
!
hostname Maracaibo
!
username Merida password 0 ciscochap
!
interface Serial1/0
description Conexion serial a Merida
ip address 192.168.1.2 255.255.255.252
encapsulation ppp
serial restart-delay 0
ppp authentication chap
!
___________________________________________________________________________

Podemos ver los eventos de autenticacion PAP y CHAP con el momando debug ppp authentication
Type escape sequence to abort.

Merida#debug ppp authentication
00:29:07: Se1/1 CHAP: O CHALLENGE id 14 len 27 from "Merida"
00:29:07: Se1/1 CHAP: I CHALLENGE id 3 len 30 from "Maracaibo"
00:29:07: Se1/1 CHAP: O RESPONSE id 3 len 27 from "Merida"
00:29:07: Se1/1 CHAP: I RESPONSE id 14 len 30 from "Maracaibo"
00:29:07: Se1/1 CHAP: I SUCCESS id 3 len 4
00:29:07: Se1/1 CHAP: O SUCCESS id 14 len 4
Merida#
Merida#
00:30:21: Se1/0 PAP: I AUTH-REQ id 3 len 23 from "Margarita"
00:30:21: Se1/0 PAP: O AUTH-REQ id 2 len 20 from "Merida"
00:30:21: Se1/0 PAP: Authenticating peer Margarita
00:30:21: Se1/0 PAP: O AUTH-ACK id 3 len 5
00:30:21: Se1/0 PAP: I AUTH-ACK id 2 len 5
Merida#ping 192.168.1.2
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms
Merida#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Reduccion del uso de la CPU en GNS3>>> Impresioante idlepc + idlemax

Usando GNS3 siempre que configuraba mas de dos router mi laptop parecia que hiba a explotar y tenia q colocar en pausa los router que no necesitava en ese momneto. Gracias a las publicaciones de unos amigos bloggeros (http://delfirosales.blogspot.com y http://journeyofanetworkengineer.blogspot.com) encontre una solucion que igual que ellos me dejo impresionado es el uso del idlepc y un valor mas llamado idlemax

Solo debemos configur del Archivo .net de la topologoa en cuestion:

autostart = False
[localhost:7200]
workingdir = .
udp = 10000
[[7200]]
image = /home/martin/cisco/gns3/ios/funcionan/c7200/c7200-ik9s-mz.122-40a.bin
idlepc = 0x605c3404
idlemax = 100
ghostios = True

martes, 18 de octubre de 2011

Frame Relay point-to-multipint + OSPF

Todos son Router c7200
IOS (tm) 7200 Software (C7200-IK9S-M), Version 12.2(40a), RELEASE SOFTWARE (fc1)
GNS3

TOPOLOGIA



Asi debemos configurar el switch FRAME-RELAY




Configuracion R1

hostname R1
!
interface Loopback0
ip address 192.168.1.3 255.255.255.0
!
interface Serial1/0
ip address 192.168.192.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 192.168.1.0 0.0.0.255 area 0
network 192.168.192.0 0.0.0.255 area 0

Configuracion R2

hostname R2
!
interface Loopback0
ip address 192.168.200.1 255.255.255.0
!
interface Serial1/0
ip address 192.168.192.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 192.168.200.0 0.0.0.255 area 0
network 192.168.192.0 0.0.0.255 area 0

Configuracion R3

hostname R3
!
interface Loopback0
ip address 192.168.232.1 255.255.255.0
!
interface Serial1/0
ip address 192.168.192.4 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 192.168.232.0 0.0.0.255 area 0
network 192.168.192.0 0.0.0.255 area 0
__________________________________________________________________________
Otra manera de hacerlo es configurando un Router como switch frame-relay



De esta manera fue configurado dejo un vistaso al running-config

hostname Switch-RF
!
frame-relay switching
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 102 interface Serial1/1 201
frame-relay route 103 interface Serial1/2 301
!
interface Serial1/1
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 201 interface Serial1/0 102
!
interface Serial1/2
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 301 interface Serial1/0 10

***El resto de los Router's (R1,R2 y R3) quedan igual a la configuracion anterior, o si queremos agregamos los mapas de frame-relay manualmente de la siguiente manera en cada una de las interfaces de los Router's:

R1
interface Serial1/0
ip address 192.168.192.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 192.168.192.2 102 broadcast
frame-relay map ip 192.168.192.4 103 broadcast

R2
interface Serial1/0
ip address 192.168.192.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 192.168.192.1 201 broadcast

R3
interface Serial1/0
ip address 192.168.192.4 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 192.168.192.1 301 broadcast

sábado, 15 de octubre de 2011

Frame-relay malla completa



CONFIGURACION

1ro configuraremos el Switch FRL

Router(config)#hosname FRL
FRL(config)#frame-relay switching


Ahora configurar las interfaces con las DLCI's

interface Serial0/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 102 interface Serial1/1 201
frame-relay route 103 interface Serial1/2 301
frame-relay route 104 interface Serial1/3 401
!
interface Serial0/1
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 201 interface Serial1/0 102
frame-relay route 203 interface Serial1/2 302
frame-relay route 204 interface Serial1/3 402
!
interface Serial0/2
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 301 interface Serial1/0 103
frame-relay route 302 interface Serial1/1 203
frame-relay route 304 interface Serial1/3 403
!
interface Serial0/3
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 64000
frame-relay intf-type dce
frame-relay route 401 interface Serial1/0 104
frame-relay route 402 interface Serial1/1 204
frame-relay route 403 interface Serial1/2 304


Congif R1

interface Serial1/0
ip address 192.168.0.1 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type cisco


Config R2

interface Serial1/0
ip address 192.168.0.2 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type cisco


Config R3


interface Serial1/0
ip address 192.168.0.3 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type cisco


Config R4

interface Serial1/0
ip address 192.168.0.4 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type cisco