EIGRP - Part 3
Habiendo ya visto conceptos básicos/intermedios del funcionamiento de EIGRP, pasaremos ahora a usar otras conceptos mas avanzados de este protocolo !
Variance
En los tiempos de guerra cuando la armada de Odín quería enfrentarse a un mismo punto usando dos caminos diferentes, tenía que estar seguro de que estos caminos tuvieran el mismo costo para llegar a su destino. Claramente esto es un ejemplo para EIGRP el cual abordaremos con la siguiente topología:
Si le damos un show ip route eigrp en R1 podremos ver que la subred 4.4.4.0/24 fue aprendida por la interfaz Eth2/0:
R1#sh ip route eigrp
!<—Output omitted—>
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/332800] via 12.0.0.2, 00:01:42, Ethernet2/0
24.0.0.0/24 is subnetted, 1 subnets
D 24.0.0.0 [90/307200] via 12.0.0.2, 00:01:42, Ethernet2/0Pero nosotros tenemos dos enlaces, uno de ellos es un enlace serial...por tanto viene la pregunta del millon: porque la subred 4.4.4.0/24 no es aprendida por la interfaz Se1/2?
Vamos a ver como se ve el output de show ip eigrp topology en R1:
R1#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(13.0.0.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 14.0.0.0/24, 1 successors, FD is 2169856
via Connected, Serial1/2
P 12.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet2/0
P 24.0.0.0/24, 1 successors, FD is 307200
via 12.0.0.2 (307200/281600), Ethernet2/0
via 14.0.0.4 (2195456/281600), Serial1/2
P 1.1.1.0/24, 1 successors, FD is 281600
via Connected, Loopback1
P 4.4.4.0/24, 1 successors, FD is 332800
via 12.0.0.2 (332800/307200), Ethernet2/0
via 14.0.0.4 (2195456/25856), Serial1/2Ahí está, escondida en la tabla de topología como sucesor factible, no fue agregada a la tabla de enrutamiento porque su métrica 2195456 es mayor a la métrica de la ruta aprendida por Et2/0 332800
Pero, nosotros no queremos que tenga una sola ruta cierto? Queremos que los paquetes vayan por ambos caminos, es decir, balancear la carga. Esto se lograba automáticamente cuando los costos eran iguales y no teníamos que configurar nada...en el default, todo era felicidad :’)
Qué podemos hacer al respecto? Vamos a usar una técnica de EIGRP llamada varianza :)
Y a todo esto...qué es la varianza? Es un factor que multiplica a la distancia factible de tal forma que si hay otras métricas menores que el resultado de esa multiplicación, se agregaran a la tabla de enrutamiento siempre en cuando cumplan la condición de factibilidad.
Mucha palabreria? Tranquilo, aquí te pongo el ejemplo práctico :D
Veamos de nuevo solo la parte de show ip eigrp topology que incluye a la subred 4.4.4.4/24
P 4.4.4.0/24, 1 successors, FD is 332800
via 12.0.0.2 (332800/307200), Ethernet2/0
via 14.0.0.4 (2195456/25856), Serial1/2Un poco de razonamiento matemático: si queremos encontrar un número que multiplicado por 332800 sea mayor o igual que 2195456 que deberíamos hacer?
Exacto! Dividir. Una estrella para ese alumno ejemplar!
2195456 / 332800 = 6.59692307692308 es decir, aproximadamente 7
Significa entonces que la varianza que usaremos es 7
Recuerdas que decía el enunciado? Vamos a verlo ahora poniendo valores:
“La varianza es un factor (varianza = 7) que multiplica a la distancia factible (FD = 332800) de tal forma que si hay otras métricas (en este caso 2195456) MENORES QUE el resultado de esa multiplicación (7*332800=2329600 entonces 2195456 < 2329600), se agregaran a la tabla de enrutamiento siempre en cuando cumplan la condición de factibilidad (es decir, distancia anunciada menor que distancia factible, en el ejemplo 25856 < 332800)”
Bueno, ahora configuremos en R1!
R1(config)#router eigrp 1
R1(config-router)#variance 7Prueba de fuego! Veamos que nos dice show ip route eigrp:
R1#show ip route eigrp
!<---Output omitted--->
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/2195456] via 14.0.0.4, 00:00:42, Serial1/2
[90/332800] via 12.0.0.2, 00:00:42, Ethernet2/0
24.0.0.0/24 is subnetted, 1 subnets
D 24.0.0.0 [90/307200] via 12.0.0.2, 00:00:42, Ethernet2/0Hell yeah! Ahora las rutas están balanceadas y los paquetes alcanzaran su destino.
IMPORTANTE: Esta configuración de varianza no es muy común, se suele hacer cuando existen problemas de balanceo de carga en EIGRP, sin embargo, es muy recomendable entenderlo pues te ayudará mucho en los exámenes asi como también entender más sobre distancia factible, distancia anunciada y condición de factibilidad.
Autenticacion
EIGRP también nos ofrece una manera de hacer los enlaces aún más privados haciendo uso de autenticación. De esta manera si un router malintencionado quiere hacerse vecino de uno que esté ejecutando el protocolo, no podrá a menos que cumpla con los términos de la autenticación.
Veamos la siguiente topología
Como sabemos, R1, R2 y R3 son vecinos EIGRP, todos conversan con el mismo protocolo asi que no tendremos problemas en ese lado.
Wait! Nos informaron que R3 no es un router de la topología, sino que es uno que algún usuario malintencionado puso en su escritorio (haters gonna hate!).
Primero, vamos a asegurarnos que para que se realice una relación de vecinos entre routers que nosotros queramos, sea autenticado mediante una llave compartida.
Lab time!
Antes que nada, comprobemos si EIGRP usa autenticación en las interfaces, veremos sólo el output en et2/1 queda como tarea para la casa ver los demás :)
R1#show ip eigrp interfaces detail ethernet 2/1
EIGRP-IPv4 Interfaces for AS(1)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Et2/1 1 0/0 58 0/2 220 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial <none>
Un/reliable mcasts: 0/4 Un/reliable ucasts: 4/2
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is not setEn este caso, la autenticación aún no está configurada.
EIGRP soporta el hash md5 para autenticación. Para hacer que ambos routers usen el mismo password, usaremos llaves.
NOTA: Cisco requiere que antes de habilitar la autenticación, un keychain debe ser configurado.
Veamos cómo se hace esto:
R1(config)#key chain LLAVERO
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string NS_EIGRPLa configuración habla por sí misma. Lo que hacemos es configurar un key chain (entiéndase como un llavero) en el cuál tendremos muchas llaves, en este caso solo usaremos una llave de nombre NS_EIGRP
Ahora, pasaremos a aplicar esto en las interfaces. Como ambos son ethernet, usaremos un interface range para configurar en ambas
Primero, habilitamos la autenticación md5:
R1(config)#interface range et2/0-1
R1(config-if-range)#ip authentication mode eigrp 1 md5Al hacer esto, el modo de autenticación no será igual en ambos lados, asi que es normal que los vecinos se pierdan con el siguiente log:
*Mar 22 04:52:11.491: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 13.0.0.3 (Ethernet2/0) is down: authentication mode changed
*Mar 22 04:52:11.519: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.2 (Ethernet2/1) is down: authentication mode changedAplicamos la llave en las interfaces:
R1(config-if-range)#ip authentication key-chain eigrp 1 LLAVEROAhora, para recuperar a R2 como vecino EIGRP, hay que configurar lo mismo en su lado. Nótese que no es necesario que el key chain tenga el mismo nombre, pero el key si debe tener el mismo nombre que en R1
R2(config)#key chain LLAVERO2
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string NS_EIGRPR2(config)#int et2/1
R2(config-if)#ip authentication mode eigrp 1 md5
R2(config-if)#ip authentication key-chain eigrp 1 LLAVERO2Automáticamente se recupera el vecino con el siguiente log:
*Mar 22 04:53:57.131: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.1 (Ethernet2/1) is up: new adjacencyComprobemos en R1 como esta la autenticación:
R1#show ip eigrp interfaces detail ethernet 2/1
EIGRP-IPv4 Interfaces for AS(1)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Et2/1 1 0/0 65 0/2 268 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial <none>
Un/reliable mcasts: 0/6 Un/reliable ucasts: 6/3
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Authentication mode is md5, key-chain is "LLAVERO"Como R3 no es un router conocido, no le hemos pasado la llave y por tanto ya no es vecino de R1, si hacemos un show ip eigrp neighbors solo veremos a R2:
R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 12.0.0.2 Et2/1 13 00:06:35 65 390 0 9Y asi una vez más defendimos la integridad del reino de Asgard encriptando los enlaces para evitar que usuarios malintencionados traten de apoderarse de la red.
Router Stub
Este es un concepto en el que normalmente los vikingos suelen tener problemas en su entrenamiento, no se entiende bien cómo es y esto dificulta un poco su ejecución.
Tranquilo, aquí te lo explicaré de una manera sencilla :)
Un router de tipo Stub es aquel que, depende de su configuración, no necesita anunciar todas sus subredes, en lugar de eso, se comporta como un router que solo recibe las rutas que le envía el vecino.
Veamos esto con un ejemplo en la siguiente topologia basica:
Haremos que R2 sea un router stub. Veamos las opciones que tenemos:
R2(config-router)#eigrp stub ?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes
<cr>Empecemos desde abajo hacia arriba:
<cr>: Si le damos enter, solo anunciara las rutas conectadas y sumarizadas por default
Summary: Sólo anunciara las rutas sumarizadas
Static: Sólo anunciara las rutas estáticas configuradas
Redistribute: Solo enviará las rutas redistribuidas
Receive-only: Sólo recibirá las rutas del vecino
Leak-map: Permitirá subredes basados en un ACL
Connected: Solo enviará las rutas directamente conectadas
Vamos a probar con un par de estas características:
R2(config)#router eigrp 1
R2(config-router)#eigrp stub receive-onlyTabla de rutas en R1
R1#sh ip route eigrp
!<—Output omitted—>Tabla de rutas en R2
R2#show ip route eigrp
!<---Output omitted--->
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/156160] via 12.0.0.1, 00:02:44, FastEthernet0/0Ahora, intentemos alcanzar la loopback de R1
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/61/68 msComo verás a pesar de que no haya rutas de retorno en R1, tenemos respuesta de R2
Intentemos usar la caracteristica static, para esto configuraremos una ruta estática de ejemplo:
R2(config)#ip route 0.0.0.0 0.0.0.0 null0Para que esto surta efecto, vamos a redistribuirlo dentro de EIGRP
R2(config)#router eigrp 1
R2(config-router)#redistribute static metric 1 1 1 1 1Con el escenario terminado, procedemos a usar static para el router de tipo stub
R2(config-router)#eigrp stub staticVamos a R1 a ver como esta la tabla de enrutamiento
R1#sh ip route eigrp
!<---Output omitted--->
Gateway of last resort is 12.0.0.2 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/2560002816] via 12.0.0.2, 00:00:22, FastEthernet0/0Yeah! Ahora solo la ruta estática se está anunciando desde R2
OBS.: Si tienes una topología bastante grande, los routers de tipo stub son recomendados pues te ayudarán a conservar recursos como CPU, memoria, etc.
Y por último, para comprobar que el vecino es un router de tipo stub, haremos el siguiente comando:
R1#show ip eigrp neighbors detail f0/0
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 12.0.0.2 Fa0/0 11 00:06:58 65 390 0 52
Version 5.0/3.0, Retrans: 0, Retries: 0, Prefixes: 2
Topology-ids from peer - 0
Stub Peer Advertising (STATIC ) Routes
Suppressing queriesY bueno como siempre...si quisieras un artículo extensivo sobre routers stub y demas, ahi tienes la sección de comentarios para requerirlo :)
NBMA
NBMA = Non Broadcast Multi-Access. En este tipo de topologías EIGRP tiene un funcionamiento especial. Un ejemplo práctico para ver esto es usando Frame Relay.
NOTA: Si tienes problemas con Frame Relay por favor deja tus dudas en la sección de comentarios, podemos hacer todo un artículo referente a ello :)
Esta sera la topologia a usar:
Para esta ejemplo, confiaremos en tus poderes de guerrero del networking y asumiremos que sabes configurar Frame Relay. En todo caso, como mencionamos antes, si tienes problemas o quieres saber cómo se configuró para este ejercicio, por favor déjanos tu opinión en la sección de comentarios :)
Vamos a ir por partes para ver de qué se trata todo esto
Parte 1: Habilitando y chequeando vecinos en EIGRP
Configuremos EIGRP en los tres routers y vemos como quedo en el running-config:
R1#sh run | se eigrp
router eigrp 1
network 1.1.1.1 0.0.0.0
network 192.168.1.1 0.0.0.0R2#sh run | se eigrp
router eigrp 1
network 2.2.2.2 0.0.0.0
network 192.168.1.2 0.0.0.0R3#sh run | se eigrp
router eigrp 1
network 3.3.3.3 0.0.0.0
network 192.168.1.3 0.0.0.0Ahora veamos los vecinos en R1
R1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
R1#Que paso? Dónde están los vecinos? Habilitamos EIGRP en todos y aun asi no vemos ninguno.
Bueno, debemos recordar que EIGRP es un protocolo que usa Multicast para enviar sus mensajes de Hello y curiosamente, esta es una red NBMA (Non Broadcast Multi-Access), significa que nada de broadcast ni multicast pasaran en esta red.
Que haremos entonces? Sencillo, vamos a habilitar el broadcast en las interfaces seriales:
R1(config)#int se1/0
R1(config-if)#frame-relay map ip 192.168.1.2 102 broadcast
R1(config-if)#frame-relay map ip 192.168.1.3 103 broadcastR2(config)#int se1/0
R2(config-if)#frame-relay map ip 192.168.1.1 201 broadcastR3(config)#int se1/0
R3(config-if)#frame-relay map ip 192.168.1.1 301 broadcastLuego de unos segundos de habilitar estas opciones, veremos el siguiente log en R1
*Mar 22 05:49:49.311: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.3 (Serial1/0) is up: new adjacency
*Mar 22 05:49:49.419: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.2 (Serial1/0) is up: new adjacencySignifica que ya tenemos vecinos. Veamos si es cierto!
R1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.1.2 Se1/0 178 00:00:01 1 2000 1 0
0 192.168.1.3 Se1/0 178 00:00:01 1 2000 1 0Yeah! Funciona como debería ser! Recuerda siempre habilitar broadcast en redes de tipo NBMA si vas a configurar EIGRP.
Parte 2: Revisando la tabla de enrutamiento
Ahora que tenemos EIGRP ejecutándose en todos los routers, vamos a ver las tablas de enrutamiento:
R1#sh ip route eigrp
!<---Output omitted--->
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2297856] via 192.168.1.2, 00:06:34, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/2297856] via 192.168.1.3, 00:06:34, Serial1/0R2#sh ip route eigrp
!<---Output omitted--->
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 192.168.1.1, 00:08:07, Serial1/0R3#sh ip route eigrp
!<---Output omitted--->
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 192.168.1.1, 00:08:20, Serial1/0Aquí nos encontramos con otro problema...porque R2 y R3 no aprenden sus loopbacks? Es decir, si queremos alcanzar la loopback de R3 desde R2 no podremos porque no está en la tabla de enrutamiento.
No me crees? Usemos ping para testear esto:
R2#ping 3.3.3.3 source 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Esto es un dilema, porque R1 no envia la informacion de las loopbacks?
Bueno, eso tiene una explicación. Esto es debido a una particularidad de los protocolos de enrutamiento que se llama split-horizon (horizonte dividido). Esta caracteristica que nos dice que si una ruta es aprendida por una interfaz, no la va a volver a enviar por la misma, de esta forma se evita tener loops de enrutamiento.
Entonces, si R1 aprende 3.3.3.3/32 por la Serial 1/0, jamas la va a enviar hacia R2 debido a que R2 esta conectado a la misma interfaz Serial 1/0 mediante Frame Relay
Cómo arreglamos esto? Sencillo, le decimos a R1 que no use la caracteristica de split-horizon. Esto está bien en este caso pues sabemos que no existe ninguna clase de loop, asi que para que se envíe todo correctamente, lo vamos a deshabilitar en la interface Serial 1/0:
R1(config)#int se1/0
R1(config-if)#no ip split-horizon eigrp 1Recibiremos unos logs de sincronización:
*Mar 22 06:06:35.655: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.2 (Serial1/0) is resync: split horizon changed
*Mar 22 06:06:35.659: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.3 (Serial1/0) is resync: split horizon changedAhora veamos como están las tablas de enrutamiento en R2 y R3:
R2#sh ip route eigrp
!<---Output omitted--->
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 192.168.1.1, 00:18:07, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/2809856] via 192.168.1.1, 00:01:24, Serial1/0R3#sh ip route eigrp
!<---Output omitted--->
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 192.168.1.1, 00:18:11, Serial1/0
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2809856] via 192.168.1.1, 00:01:27, Serial1/0No es hermoso? :’) Ahora las tablas de enrutamiento están completas, veamos que sucede con el test de hace un rato:
R2#ping 3.3.3.3 source 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 msHell yeah! Carne y cerveza para todo el mundo por el logro obtenido! \m/
Conclusiones
Esta es la parte final de la serie EIGRP. Se que por algún lugar se me paso alguna información sobre todo lo que es el protocolo, si hay algún tema en especifico que quieras abordar, por favor déjalo en la sección de comentarios.
Live long and prosper!
