EIGRP – Part 2
En un post anterior hemos visto lo básico de EIGRP, una configuración inicial y comprobación de que está siendo usado. En este post veremos algunos temas adicionales que deben saberse para entender mejor el funcionamiento y comportamiento de EIGRP.
Let's go!
Métrica - Distancia Administrativa
Cuando hablamos de cualquier protocolo de enrutamiento, no podemos dejar de mencionar los conceptos de métrica y distancia administrativa. Es de esperar que a este punto de tu entrenamiento sepas que significa cada uno.
No lo recuerdas o no lo sabes? Tranquilo, comete un snickers y lee aquí una explicación sobre estos conceptos.
Lo primero que te preguntarás es: “en dónde puedo ver la Distancia Administrativa y la Métrica?” Bueno, eso es sencillo, están visiblemente en donde se muestran las rutas...exacto...la tabla de enrutamiento. Esto lo podemos ver fácilmente con el comando show ip route:
D 2.2.2.2 [90/156160] via 10.0.0.2, 00:59:34, FastEthernet0/0Como te puedes dar cuenta, hay dos números entre corchetes, estas son la Distancia administrativa y la Métrica para una ruta aprendida por EIGRP.
Veamos un poco de palabrería 😁
- Distancia administrativa: Es un número que expresa el nivel de importancia de una ruta, en el ejemplo, si la subred 2.2.2.2 hubiese sido aprendida por EIGRP y RIP a la vez, con el fin de que no existan rutas duplicadas en la tabla, el router debe decidir cual de los dos protocolos tiene mas importancia. En este caso, será EIGRP pues tiene la menor distancia administrativa.
Confuso? Mira la siguiente tabla, la hemos ordenado por protocolo para una mejor referencia:
|
Protocolo |
Distancia Administrativa |
|
EIGRP |
90 |
|
EIGRP - Exterior |
170 |
|
OSPF |
110 |
|
RIP |
120 |
|
iBGP |
200 |
| eBGP |
20 |
Ahora si se ve mejor? Las distancias administrativas están asignadas por default, y para que el router prefiera un protocolo sobre el otro, es necesario comparar estos números. Asi pues, la menor distancia administrativa será la preferida.
- Métrica: Si la Distancia Administrativa nos mostraba que protocolo era mejor que otro, la Métrica nos va a mostrar la mejor ruta dependiendo de su origen.
Otra vez piensas ”que hablas??”. Bien, esto se verá mejor en un gráfico:

Si la subred de la interface Loopback0 de R3 (3.3.3.3) es aprendida por ambas interfaces de R2, por motivos didácticos y para que tu sharingan se pueda entrenar, pusimos como métricas 300 y 2000
3.3.3.3 [90/300] via 32.0.2.1, 00:07:37, Ethernet2/0
3.3.3.3 [90/2000] via 32.0.1.1, 00:07:37, Ethernet2/1La pregunta es, cómo decidirá el router cuál de las es la ruta preferida para enviar paquetes? Acertaste. Viendo su Métrica. Entonces, si tú fueras R1, que pensarías? Por supuesto, elegir la Ruta1 con métrica 300
Luego de decidirse, R2 instalará la ruta en la tabla de enrutamiento como:
D 3.3.3.3 [90/300] via 32.0.2.1, 00:07:37, Ethernet2/0Y la otra? Es enviada al oscuro olvido? La respuesta es no, será conservada por el router como una ruta de backup en caso se caiga la principal.
Cool huh?
Obs. La Métrica a diferencia de la Distancia administrativa no es un valor por defecto, se calcula usando unas variables especiales y una fórmula algo grande, veremos esto en el apartado K values.
Auto-summary
EIGRP nos ofrece la opción de poder sumarizar en una red de clase A, B o C las subredes aprendidas, esta caracteristica es conocida como Auto-summary. No es una opción muy común usada en el campo de batalla pero es bueno saberlo, después de todo, todo conocimiento en networking es bienvenido verdad? -habló mi lado geek 😊
Si escribo demasiado quizás te enredes en las palabras, o como decimos en Perú, mucho floro! Entendamos este Auto-summary en 3 secciones: Cómo es, Cuando usarlo Cuando no usarlo
- Cómo es

Obs.: Para estos ejemplo estamos usando IOS 15.0(1) A partir esta versión Auto-summary está deshabilitado por defecto, en estos labs lo volveremos a habilitar.
Configuremos EIGRP básico y veamos como se ve la tabla de enrutamiento en R2
R2(config)#int et2/1
R2(config-if)#ip add 12.0.0.2 255.255.255.252
R2(config-if)#no shut
R2(config-if)#int et2/3
R2(config-if)#ip add 23.0.0.1 255.255.255.252
R2(config-if)#no shut
R2(config)#router eigrp 1
R2(config-router)#net 12.0.0.2 0.0.0.0
R2(config-router)#net 23.0.0.1 0.0.0.0
R2(config-router)#no auto-summaryR2#sh ip route eigrp
!---<Output omitted>
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/409600] via 12.0.0.1, 00:00:57, Ethernet2/1
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/409600] via 23.0.0.2, 00:00:09, Ethernet2/3Como puedes ver, las subredes están siendo aprendidas con la máscara configurada (/24). Veamos qué sucede en R2 cuando habilitamos Auto-summary en los routers con el comando auto-summary:
R2#sh ip route eigrp
!---<Output omitted>
D 1.0.0.0/8 [90/409600] via 12.0.0.1, 00:01:49, Ethernet2/1
D 2.0.0.0/8 [90/409600] via 23.0.0.2, 00:00:04, Ethernet2/3
12.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
D 12.0.0.0/8 is a summary, 01:28:19, Null0
23.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
D 23.0.0.0/8 is a summary, 01:28:19, Null0Ahora EIGRP está aprendiendo toda la clase (/8)
Hey, y esas interfaces Null0? Recuerda que R1 tambien tiene una direccion IP en el espacio de 12.0.0.0/8 que tambien esta siendo anunciada (12.0.0.2/30). Esta interface Null0 es una suerte de protección contra paquetes que no se encuentran dentro de esa subred, significa que los paquetes van a ser descartados. Ejemplo:
Digamos que R2 recibe un paquete hacia la direccion 12.100.1.10/28 pero como sabemos, este rango no se encuentra en la tabla de enrutamiento. Como EIGRP auto-sumariza en la clase entera, si no existiera esa Null0, el paquete seria enrutado normalmente pues 12.100.1.0/28 esta dentro de 12.0.0.0/8 verdad? Entonces Null0 es una protección contra posibles loops de enrutamiento.
Si aún te parece complicado el asunto de Null0 -que también se suele usar en rutas estaticas como tecnica para descartar paquetes- haremos un articulo hablando sobre esto, si te parece buena idea, por favor tus sugerencias en la sección de comentarios :)
- Cuando usarlo
Debido a que EIGRP puede sumarizar las subredes, sería conveniente si se usa en un universo en el que las subredes se pueden sumarizar sin problemas de loop. Veamos un ejemplo con la siguiente topología:

Ya sabes la rutina, EIGRP basico, configurar las interfaces, etc etc. Vamos al grano y luego de configurar todo, hagamos un show ip route eigrp en R2 a ver que tal quedo:
R2#sh ip route eigrp
!---<Output omitted>
172.16.0.0/24 is subnetted, 5 subnets
D 172.16.1.0 [90/156160] via 12.0.0.1, 00:03:05, FastEthernet0/0
D 172.16.2.0 [90/156160] via 12.0.0.1, 00:03:05, FastEthernet0/0
D 172.16.3.0 [90/156160] via 12.0.0.1, 00:03:05, FastEthernet0/0
D 172.16.4.0 [90/156160] via 12.0.0.1, 00:03:05, FastEthernet0/0
D 172.16.5.0 [90/156160] via 12.0.0.1, 00:03:05, FastEthernet0/0Ahora habilitamos auto-summary en ambos routers y veamos que sucedió:
R1(config)#router eigrp 1
R1(config-router)#auto-summaryR2(config)#router eigrp 1
R2(config-router)#auto-summary R2#sh ip route eigrp
!---<Output omitted>
D 172.16.0.0/16 [90/156160] via 12.0.0.1, 00:00:45, FastEthernet0/0El poder de EIGRP se observa ahora! Sumarizó todas las entradas de 172.16.X.X en la clase. Asi, si quisieramos agregar más subredes del tipo 172.16.X.X no habrá necesidad de configurarla con el comando network pues EIGRP ya conoce la subred de clase (172.16.0.0/8)
- Cuando no usarlo
En la sección anterior vimos como podíamos aprovechar el poder de Auto-summary, ahora veremos que sucede en la realidad, en casos en los que podamos tener alguna inconsistencia. Usemos la siguiente topología:

Bueno, ya sabes lo que diré: “EIGRP basico, interfaces, blah blah”...
...y por supuesto, veamos como se ve el output de show ip route eigrp en R1
R1#sh ip route eigrp
!---<Output omitted>
172.16.0.0/24 is subnetted, 10 subnets
D 172.16.1.0 [90/409600] via 12.0.0.2, 00:02:13, Ethernet2/0
D 172.16.2.0 [90/409600] via 12.0.0.2, 00:02:13, Ethernet2/0
D 172.16.3.0 [90/409600] via 12.0.0.2, 00:02:13, Ethernet2/0
D 172.16.4.0 [90/409600] via 12.0.0.2, 00:02:13, Ethernet2/0
D 172.16.5.0 [90/409600] via 12.0.0.2, 00:02:13, Ethernet2/0
D 172.16.6.0 [90/409600] via 13.0.0.2, 00:00:25, Ethernet2/1
D 172.16.7.0 [90/409600] via 13.0.0.2, 00:00:23, Ethernet2/1
D 172.16.8.0 [90/409600] via 13.0.0.2, 00:00:20, Ethernet2/1
D 172.16.9.0 [90/409600] via 13.0.0.2, 00:00:16, Ethernet2/1
D 172.16.10.0 [90/409600] via 13.0.0.2, 00:00:13, Ethernet2/1Una preciosa tabla de enrutamiento! Todo está bien aprendido, las rutas están anunciadas con su correcta máscara de subred...sería una lástima que alguien malogre la configuración… :D
Habilitemos Auto-summary en R2 y R3 y veamos como se ve R1
R1(config)#router eigrp 1
R1(config-router)#auto-summaryR2(config)#router eigrp 1
R2(config-router)#auto-summaryR1#sh ip route eigrp
!---<Output omitted>
D 172.16.0.0/16 [90/409600] via 12.0.0.2, 00:00:10, Ethernet2/0Que sucedio? A dónde se fueron todas las redes? Bueno, todas fueron sumarizadas en la red de clase 172.16.0.0/16 ahora, ves el peligro de usar Auto-summary? La ruta de clase está siendo aprendida por la interface et2/0 la cual está conectada a R2, significa que desde R1 las redes de R3 no son alcanzables
No me crees? Hagamos la prueba :D
Alcanzamos las redes de R1...
R1#ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/24 ms...Pero ninguna de R3
R1#ping 172.16.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.6.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)Moraleja de la historia: lleva siempre cerveza, un hacha, un escudo y por Odin, asegurate de que Auto-summary este deshabilitado :)
Advertise distance/feasible distance
Esta es quizás la parte más importante y fundamental de EIGRP, en esta sección veremos cómo es que el algoritmo DUAL reacciona ante cambios en la red y elige un camino alternativo automáticamente. Para lograr esta hazaña heroica, EIGRP usa dos valores fundamentales Advertise distance y Feasible distance.
- Advertise distance
Es la conocida como Distancia Anunciada, es la métrica que el router vecino nos envía para decirnos: “Hey, este es el camino corto que tengo para llegar a una red 😁”
Ahora, como los routers además de tímidos también son desconfiados, toman este valor y lo guardan para analizarlo después, de esta manera, tendrá en su base de datos todas las distancias anunciadas por los vecinos.
Y como sabe el router quien tiene el mejor camino? Para esto existe lo que se llama Feasible distance.
- Feasible distance
Conocida como Distancia factible, es la que obtendremos luego de analizar las rutas y métricas obtenidas de los vecinos. El router hará una inspección de las distancias anunciadas y tomará aquella que se presente como la ruta más óptima.
Y bueno...se que dirás que hago lo mismo que todo el mundo y solo palabreo...ok ok, aquí un ejemplo práctico que te ayudará a entender todo el floro 😁
Veamos la siguiente topología:

Este grafico nos cuenta una pequeña historia de como es que R1 reconoce las distancias hacia la subred 10.1.1.0/2 y como instala las mismas en su tabla de enrutamiento y en su tabla de topologia. Veamos el siguiente dialogo entre R1, R2 y R3:
R1: “Hey, quiero llegar a la subred 10.1.1.0/24 pero no se que camino tomar u.u quizás mis vecinos R2 y R3 conozcan la subred”R2: “Yo conozco la subred! Está a una distancia de 30 desde mi posición! :)”R3: “Yo tambien la conozco! Se encuentra a 65 desde donde estoy :)”
Ahora, cuál elegirá R1?
Por supuesto, el camino ofrecido por R2 pues su distancia anunciada es la más óptima. Por lo tanto, en la tabla de enrutamiento se instalará la ruta por R2
Y la ruta de R3? Bueno para entender qué sucede con esta ruta, debemos tener otros conceptos en claro. Veamos de qué se trata usando una topología de prueba:

NOTA: Las loopbacks tienen como valor el router en el cual fueron asignadas, por ejemplo, la loppback de R1 sera 1.1.1.1
Tabla de enrutamiento: Esta tabla nos muestra las rutas que han sido instaladas en el router, como esto ha sido tratado en un artículo anterior sólo mostraremos como ejemplo como se ve una tabla de enrutamiento del protocolo EIGRP
R2#show ip route eigrp
!---<Output omitted>
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/409600] via 12.0.0.1, 00:19:09, Ethernet2/1
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/409600] via 23.0.0.3, 00:19:04, Ethernet2/2
13.0.0.0/24 is subnetted, 1 subnets
D 13.0.0.0 [90/307200] via 23.0.0.3, 00:19:09, Ethernet2/2
[90/307200] via 12.0.0.1, 00:19:09, Ethernet2/1De aqui vemos que la subred 13.0.0.0 es aprendida por 23.0.0.3 y 12.0.0.1 (routers R3 y R1 respectivamente), sin embargo la subred 1.1.1.1 solo es conocida mediante el router R1. Si se mira bien, hay dos posibles caminos para conocer esta subred:
R1 → R2
R1 → R3 → R2
Y porqué en la tabla de enrutamiento no aparece la ruta R1 → R3 → R2? Si estuviera ahí tendríamos una línea parecida a esta:
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/409600] via 12.0.0.1, 00:19:09, Ethernet2/1
[90/435200] via 23.0.0.3, 00:19:09, Ethernet2/2Bueno, todo tiene explicación en esta vida! Para conocer un poco más a detalle como EIGRP decide instalar las rutas, veamos la tabla de topología.
Tabla de topología: Esta tabla nos mostrará como las rutas son aprendidas por EIGRP se puede ver con el comando show ip eigrp topology, veamos el output para este ejemplo
R2#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 13.0.0.0/24, 2 successors, FD is 307200
via 12.0.0.1 (307200/281600), Ethernet2/1
via 23.0.0.3 (307200/281600), Ethernet2/2
P 12.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet2/1
P 23.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet2/2
P 2.2.2.2/32, 1 successors, FD is 128256
via Connected, Loopback1
P 3.3.3.3/32, 1 successors, FD is 409600
via 23.0.0.3 (409600/128256), Ethernet2/2
P 1.1.1.1/32, 1 successors, FD is 409600
via 12.0.0.1 (409600/128256), Ethernet2/1Como puedes ver, esto muestra cada una de las rutas con sus sucesores, en el caso de 13.0.0.0 tiene dos posibles caminos pues tiene el mismo valor de Feasible Distance.
Pero esto aun no nos responde la pregunta, que sucedio con la ruta de 1.1.1.1 a traves del router R3? Bueno, no aparece en la tabla de topología por una buena razón: no cumple la condición de factibilidad.
Que es?...a continuación te explico :)
Condición de factibilidad: Esta condición establece: “si la DISTANCIA ANUNCIADA es ESTRICTAMENTE MENOR que la DISTANCIA FACTIBLE, entonces la ruta se vuelve un Sucesor Factible”
Esto lo podemos ver en la tabla de topología anterior, esta vez añadiremos la opción all-links y veamos que sucede:
R2#sh ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(1)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 13.0.0.0/24, 2 successors, FD is 307200, serno 6
via 12.0.0.1 (307200/281600), Ethernet2/1
via 23.0.0.3 (307200/281600), Ethernet2/2
P 12.0.0.0/24, 1 successors, FD is 281600, serno 1
via Connected, Ethernet2/1
P 23.0.0.0/24, 1 successors, FD is 281600, serno 4
via Connected, Ethernet2/2
P 2.2.2.2/32, 1 successors, FD is 128256, serno 5
via Connected, Loopback1
P 3.3.3.3/32, 1 successors, FD is 409600, serno 8
via 23.0.0.3 (409600/128256), Ethernet2/2
via 12.0.0.1 (435200/409600), Ethernet2/1
P 1.1.1.1/32, 1 successors, FD is 409600, serno 3
via 12.0.0.1 (409600/128256), Ethernet2/1
via 23.0.0.3 (435200/409600), Ethernet2/2Voila! Aqui vemos a nuestro amigo 1.1.1.1 que es conocido por los routers R1 y R3, pero como vemos, la ruta via 23.0.0.3 (435200/409600), Ethernet2/2 no fue añadida a la tabla de topologia pues su distancia anunciada 409600 es igual que la distancia factible 409600, recuerda que para que se cumpla la condicion de factibilidad, debe ser estrictamente menor.
Y porque es tanta complicación? Para evitar loops de enrutamiento.
Esto obviamente se puede conocer de forma extensiva, la tabla de topología es algo extensa y seria buena idea dedicar un artículo dedicado a ello. Si te parece buena idea, por favor déjalo en la sección de comentarios :)
Timers
Como ya es conocido, para que los routers puedan hablar el mismo idioma de EIGRP deben enviarse entre ellos paquetes Hello, si no lo reciben en un determinado tiempo (llamado Dead time), el router pensará: “El otro router no me envía paquetes Hello, debe estar resentido conmigo u.u” y procede a lanzar la alerta de que cayo el vecino y otra ruta alterna sera tomada. Pero sabemos que esto no es asi, el link esta activo solo que los paquetes Hello están demorando en llegar. Qué podemos hacer al respecto?
Primero hay que preguntarnos, cada cuanto tiempo se envían estos paquetes? Bien, el tiempo por defecto en una conexión LAN, el paquete Hello es enviado cada 5 segundos y el Dead es de 15 segundos. Oh lo notaste? El Dead es el triple del Hello 😎. Para el caso de los enlaces WAN el Hello es de 60 y el Dead es de 180
Como podemos chequearlo? En el detalle de las interfaces participes de EIGRP se puede ver el Hello time y Hold time configurados:
R2#show ip eigrp 1 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 554 0/2 2700 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/2
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not setQue pasaria si la red fuera lenta y necesitamos que esos 5 segundos sean 30? Bueno, podemos hacer una configuración para cambiar estos valores por defecto.
R2#conf t
R2(config)#int et2/0
R2(config-if)#ip hello-interval eigrp 1 30Ahora, veremos si se cambio el tiempo:
R2#sh ip eigrp 1 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 554 0/2 2700 0
Hello-interval is 30, Hold-time is 15
Split-horizon is enabled
Next xmit serial <none>
Un/reliable mcasts: 0/6 Un/reliable ucasts: 6/2
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not setYeah! Logramos cambiar el tiempo del Hello exitosamente :D
Y que paso con el Hold time? Aun se quedo en 15, significa que también hay que cambiarlo manualmente, eso sí, no olvidarse de la proporción Hold-time = 3x(Hello-time)
R2(config-if)#ip hold-time eigrp 1 90Veamos ahora si se actualizó:
R2#sh ip eigrp 1 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 72 0/2 272 0
Hello-interval is 30, Hold-time is 90
Split-horizon is enabled
Next xmit serial <none>
Un/reliable mcasts: 0/12 Un/reliable ucasts: 15/5
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not setHell yeah! Ahora si tenemos los tiempos a medida.
IMPORTANTE: Este cambio en los tiempos del Hello y del Hold time son recomendados cuando se tiene planeado cómo va a trabajar EIGRP. No es necesario que ambos routers tengan los mismos tiempos pues no es una condición para establecer conectividad.
K Values
Para terminar este “pequeño” artículo, veremos un poco de como EIGRP calcula la métrica para las rutas.
El cálculo de la métrica se realiza usando una fórmula algo grande. Como ya lo habíamos visto en un artículo anterior, EIGRP usa 5 valores para hacer esta operacion:
|
K1 |
Bandwidth |
|
K2 |
Load |
|
K3 |
Delay |
|
K4 |
Reliability |
| K5 |
MTU |
La fórmula utilizada es la siguiente:

Bastante grande eh? No te alarmes, relax, hay buenas noticias, los valores por defecto de K son: K1=1, K2=0, K3=1, K4=0, K5=0 y según la documentación de EIGRP cuando K5=0 entonces se puede considerar (K5/K4+Reliability)=1
De este modo, la fórmula quedaría como:
(Bandwidth+Delay)*256
Ahora si se ve mas elegante 😊
Y a todo esto...a que queremos llegar? Bueno, pueden haber ocasiones especiales en las que se requiera configurar o ajustar los valores de K (generalmente esto sucede con clientes muy especiales...y creeme que los hay ahí afuera!).
Veamos cómo ajustar estos valores, haciendo honor a nuestra costumbre, comandos primero y explicación después 😁
IMPORTANTE: Recuerda que para que dos routers puedan hablar EIGRP deben tener los valores de K iguales, sino habría errores de mismatch y no podrían llegar a ser neighbors.
No me crees? Lab time!!!
Usemos la siguiente topología simple

Configuremos EIGRP básico en ambos...como en este punto ya eres un erudito de lo basico de EIGRP, sólo asumiremos que ya lo tienes completado y ejecutaremos el comando show ip protocols para comprobar los valores de K en nuestra configuración de EIGRP:
R1#show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
Redistributing: eigrp 1
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 1.1.1.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
1.1.1.1/32
12.0.0.1/32
Routing Information Sources:
Gateway Distance Last Update
12.0.0.2 90 00:01:34
Distance: internal 90 external 170Antes de realizar algún cambio, veamos como se ve la métrica de EIGRP:
R1#sh ip route eigrp
!---<Output omitted>
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/409600] via 12.0.0.2, 00:28:44, Ethernet2/1Ahora cambiemos los valores de K en el router R1, para hacer las cosas prácticas, colocaremos todos los valores de K = 1
R1#conf t
R1(config)#router eigrp 1
R1(config-router)#metric weights 0 1 1 1 1 1Obs.: El primer valor es ToS (Type of Service) y se usará siempre el valor de 0. Obviamente esto tiene una razón algo extensa, y de nuevo con lo mismo...si quieres profundizar o que se publique un artículo sobre ello, déjalo en la sección de comentarios :)
Y ahora vemos que en la consola se muestra el siguiente log:
*Mar 18 02:03:40.631: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.2 (Ethernet2/1) is down: metric changed
*Mar 18 02:03:41.823: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.2 (Ethernet2/1) is down: K-value mismatchY en R2 algo similar:
R2#
*Mar 18 02:06:20.463: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.1 (Ethernet2/1) is down: K-value mismatchOk, esto significa que a R2 no le está gustando que R1 hable con valores de K diferentes, veamos que sucede cuando configuramos los mismos valores de K en R2:
R2(config)#router eigrp 1
R2(config-router)#metric weights 0 1 1 1 1 1
*Mar 18 02:07:40.291: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 12.0.0.1 (Ethernet2/1) is up: new adjacencyVoila! ahora si esta como debe ser 😄 Ahora, veamos cómo cambio la métrica:
R1#sh ip route eigrp
!---<Output omitted>
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/1603] via 12.0.0.2, 00:01:18, Ethernet2/1Tarea para la casa: agarra una calculadora y comprueba que este valor sea exacto :D
Como podras darte cuenta, cambiar los valores de K en un router implica que hay que cambiarlo en el otro router, significa que si tenemos 50 routers y queremos cambiar los valores de K en uno de ellos, habrá que hacerlo en los otros 49 restantes.
Por eso se aconseja solo dejar los valores de K por defecto, pero ya sabes...en gustos y colores…😉
Conclusiones
Con esto hemos finalizado el segundo artículo de EIGRP de esta serie de La Ruta del Guerrero - EIGRP. En una próxima entrega veremos algunos temas que aún faltan abordar.
Hasta la próxima! \m/