EIGRP – Part 2

Share
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/0

Como 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 😁

  1. 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.

  1. 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/1

La 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/0

Y 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/3

Como 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, Null0

Ahora 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/0

Ahora 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/0

El 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/1

Una 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/0

Que 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/1

De 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/2

Bueno, 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/1

Como 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/2

Voila! 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 set

Que 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 30

Ahora, 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 set

Yeah! 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 90

Veamos 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 set

Hell 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 170

Antes 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/1

Ahora 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 1

Obs.: 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 mismatch

Y 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 mismatch

Ok, 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 adjacency

Voila! 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/1

Tarea 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/