lunes, 9 de marzo de 2009

Conceptos de EIGRP Parte I.

Mucho hemos hablado últimamente del tema del famoso EIGRP y sus bondades.

En diversos materiales de Cisco he leído que EIGRP es el protocolo de enrutamiento que más rapido converge, a la vez de que posee muchas variables para establecer el cálculo de la métrica a cada destino y que no consume tanta memoria ni recursos de CPU como los algoritmos de estado enlace. Sumado a esto proporciona balanceo de carga en enlaces desiguales, por lo que resulta una opción más que interesante para evaluar al momento de elegir un protocolo de enrutamiento para nuestra red.

Vamos a ver algunos detalles de los puntos que mencionamos anteriormente:

Antes que nada es necesario aclarar que nos encontramos ante un protocolo que está patentado por Cisco Systems, por lo que sólo podrá ser usado si es que tenemos una red en donde poseemos equipos de esa marca en los puntos donde debe haber enrutamiento. Para los que no tengan todos los equipos de la marca o bien vengan con una línea de pensamiento de estandarización y tecnologías abiertas, mejor vayan por alguno de los otros protocolos.

Una vez aclarado esto, podemos decir que no se sabe a ciencia cierta como está desarrollado el protocolo, aunque se sabe que toda la magia está centrada en su núcleo  DUAL (Diffusing Update ALgorithm), que se encarga de calcular las mejores rutas libres de loops hacia cada destino en particular.
Hay un paper que describe brevemente el algoritmo y puede ser visto aquí.

EIGRP es catalogado en la mayoría de los libros como un protocolo de vector distancia mejorado  y en otros como un híbrido. La cantidad de saltos que se debe atravesar se encuentra presente en la información de cada ruta, pero este dato no interviene en el cálculo de la métrica.
Tengamos en cuenta que el límite de saltos para una ruta que se aprende por EIGRP es 224, y 255 para su antecesor: el viejo IGRP.

El dato anterior no es un detalle menor (dado que casi nadie publica esta información) pero a estas si tenemos un destino que está detrás de más de 224 saltos estamos teniendo un problema grave o bien estamos haciendo todo mal, por lo que estas distancias máximas permitidas por el protocolo son por demás de aceptables.

Otras bondades del protocolo son:
  • Dado que envía la máscara de red en las actualizaciones, soporta VLSM.
  • Soporta el envío de actualizaciones parciales hacia los vecinos.
  • Soporta varios protocolos de capa tres mediante la inclusión de los módulos PDM (Protocol Dependent Modules).
  • Tiene su propio protocolo de transporte de información, llamado RTP (Reliable Transport Protocol).
  • Detecta a sus vecinos intercambiando mensajes de saludos al igual que los protocolos de estado enlace.
  • Es relativamente fácil de configurar.
  • Puede definirse administrativamente la cantidad de ancho de banda que se utilizará en las actualizaciones.
  • Detecta automáticamente las redes NBMA (multiacceso sin broadcast) tales como las topologías de frame-relay multipunto.


    • Estas topologías son un dolor de cabeza a la hora de configurar los otros protocolos.



  • Sus métricas son de 32 bits, por lo que ofrece una gran granularidad.

Tiene diversos componentes para evaluar la métrica, y estos pueden ser activados según las necesidades del administrador:
  • Ancho de banda.
  • Retraso.
  • Confiabilidad.
  • Carga del enlace.
  • MTU(*).

El cálculo de la métrica se define según la siguiente ecuación:




No me voy a detener en este post a explicar cada una de estos puntos, sino que voy a hablar puntualmente de por qué el protocolo converge más rápido que el resto:

Supongamos que tenemos esta topología:




Tengamos en cuenta que los costos del camino están simplificados a fin de que se entienda mejor la explicación.

Nuestra PC está conectada al Router Oeste, que posee tres enlaces hacia el Router Este que contiene la red de destino, 192.168.90.0/24.

Debido a que los tres enlaces son de diferentes ISP, los anchos de banda y el delay (variables K1 y K3 habilitadas por defecto) de cada uno nos generan una distinta métrica.

Analicemos ahora las distancias para llegar hacia la red 192.168.90.0/24:
  • 30 (20+10) para llegar mediante el router Norte.
  • 20 (10+10) para llegar mediante el router Centro.
  • 275 (20+255) para llegar mediante el router Sur.

Es evidente que el mejor camino es pasando por el router Centro, por lo que esa es la ruta que EIGRP instalará en nuestra tabla de enrutamiento.
A esta ruta la llamaremos Ruta Sucesora.

Observemos también que las otras dos rutas son válidas, dado que  representan caminos sin bucles (loops).

Para esto, vamos a seguir definiendo términos:

El Router Oeste cuenta con datos como una Distancia Factible (Feasible Distance, FD) que es la distancia calculada por Oeste hasta la red remota, que en este caso es de 20 pasando por Router Centro que a su vez,  le "reporta" al Router Oeste que su distancia hacia la red remota (la distancia desde el Router Centro) es de 10.

A esta distancia se la llama Distancia Reportada (Reported Distance, RD).

O sea que el Router Oeste cuenta con los siguientes datos para calcular la FD hacia la red 192.168.90.0/24:
Tengo una distancia de 20 hacia Router Norte, el me reporta una distancia de 10 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 30.

Tengo una distancia de 10 hacia Router Centro, el me reporta una distancia de 10 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 20.

Tengo una distancia de 20 hacia Router Sur, el me reporta una distancia de 255 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 275.

Instalaré en la tabla de enrutamiento una entrada calculada mediante DUAL pasando por Router Centro para llegar a la red 192.168.90.0/24.

EIGRP va a guardar los otros caminos en su tabla de topología, y prestará extrema atención a aquellos que cumplan con la llamada Condición de Factibilidad que define lo siguiente:
Serán rutas de backup o alternas llamadas Sucesoras Factibles (Feasible Successors) las rutas que tengan una distancia reportada (RD) menor que la distancia factible (FD).

Por esto, si analizamos el diagrama según el punto de vista del Router Oeste:
  • La ruta a través de Centro es la sucesora, por lo que no la analizamos.
  • La ruta a través de Norte tiene una RD de 10, que es menor que mi FD hacia la red 192.168.90.0/24. Esta ruta cumple la condición de factibilidad. La instalo como sucesora factible en mi tabla de topología.
  • La ruta a través de Sur tiene una Distancia Reportada (RD) de 255, que es mayor que la distancia factible (FD) igual a 20. Esta ruta no cumple la condición de factibilidad, por lo que no la considero como backup.





En caso de que se caiga el enlace entre Router Oeste y Router Centro, la ruta sucesora factible será automáticamente promovida a Sucesora, sin tener que recalcular nada.
Esto es lo que hace extremádamente rápido al protocolo en términos de velocidad de convergencia.




En caso de que la nueva sucesora falle, Router Oeste no va a tener otra ruta backup, por lo que va a mandar consultas acerca de 192.168.90.0/24 a todos los vecinos que estén disponibles.

En este momento, EIGRP va a calcular activamente cómo llegar a la red destino, por lo que las rutas que sean inalcanzables aparecerán como A (Ruta Activa).




Acto seguido realizará un Query (consulta) a sus vecinos activos para ver si alguno de ellos tiene una ruta sin bucles hasta la red de destino.




El router Sur va a responder diciendo que conoce una ruta para llegar a la red en cuestión y se lo informa a Oeste.




Ahora el único camino hacia la red remota es vía el Router Sur, por lo que se transforma en sucesor.




Esto es parte de lo que debería saber cualquier CCNA. En la siguiente entrega veremos como realizar el bendito balanceo de carga con enlaces desiguales.

Salud!

18 comentarios:

fede dijo...

Hola de nuevo Ariel,
veras no entiendo la formula d la metrica, si k5=0 entonces queda 0*256 lo que es igual a 0,¿metrica 0?

¿me puedes aclarar esto??
Gracias

Ariel Weher dijo...

La fórmula básica del cálculo de la métrica (la default) es: 256x(Bandwidth + Delay).
El IOS viene por defecto con K1 y K3 en 1, los demás en 0.
En caso que un valor K5 sea cero, entonces esa parte de la ecuación no se tiene en cuenta.

Saludos

fede dijo...

perdona pero no lo veo, me sale [(BW+Delay)*0]*256=0!!!

Ariel Weher dijo...

La fórmula básica del cálculo de la métrica (la default si no tocas los K) es: 256x(Bandwidth + Delay). No veo de donde sacas todos tus ceros. El delay y el ancho de banda nunca son cero.

Saludos

fede dijo...

perdona las molestias Ariel,
[(BW+Delay) * (k5/(k4+confiabilidad)]*256=0!!!

Ariel Weher dijo...

Sinceramente no entiendo que quieres decir con eso o cual es la pregunta...

Saludos

fede dijo...

la formula es : [(BW+Delay) * (k5/(k4+confiabilidad)]*256, OK??
k5/k4=0, por tanto queda (BW+DLY)*0 que es igual a 0, ¿¿es correcto??
perdona, pero igual estoy equivocado, ¿¿me lo aclaras??

Ariel Weher dijo...

Vuelvo a insistir:

La fórmula básica del cálculo de la métrica (si no tocas los "K" 1 0 1 0 0) es: 256x(Bandwidth + Delay).
Ahi se termina el cálculo.
Una métrica de EIGRP no puede dar cero.

fede dijo...

¿¿entonces k5/(k4 + confiabilidad) es igual a 1??
¿como puede ser?

Ariel Weher dijo...

Vuelvo a insistir:

Si K4 = 0 ó K5 = 0. esa parte de la fórmula SE ELIMINA. Quedando 256 x (BW + Delay).
Ahi se termina el cálculo.

Saludos

fede dijo...

pokito a poco vamos progresando...........
en la documentacion de cisco tambien pone que se elimina, pero ¿porque se elimine y no "afecta" a la formula?

Gracias de nuevo Ariel:D

segpaa dijo...

como k5 y k4 son =0 entonces la division tiende a 1 y es como multiplicar por 1

fede dijo...

Gracias por tu respuesta segpaa :D

0/1 "igual a " 1?? no me convence mucho ehh .....pero gracias segpaa:D, saludos

Ariel Weher dijo...

Fede, hay un IF en el algoritmo.
Si K4 ó K5 son cero, entonces se usa otra fórmula. Nadie sabe bien como es EIGRP porque es código cerrado de Cisco.
Además te puedo contar que nunca vi alguna implementación con los valores K modificados del default y encima Cisco recomienda NO cambiarlos, por ende, se usa siempre la fórmula corta aunque como siempre tenés la posibilidad de tocar esto.

Es más, en tu exámen de CCNA vas a tener que configurar EIGRP teniendo en cuerta la fórmula corta.

Saludos y gracias como siempre.

Anónimo dijo...

Se agradece toda la informacion publicada en esta pagina; pero tadavia no me queda claro la parte de configuracion del bandwidth y el delay, osea en que nos basamos al poner las candidades al bandwidth y al delay, porque vi una configuracion eigrp donde dicen que es importante colocar valores al delay y al bandwidth pero no dicen en que se basan al colocar esos numeros; se agradece por anticipado su respuesta

Ariel S. Weher dijo...

En la configuración por defecto sólo se tienen en cuenta el ancho de banda y el delay como variables utilizadas para calcular la métrica. Vos lo que podrías hacer es modificar los valores K (en todos los equipos) para desestimar alguna de estas variables, o bien habilitar alguna del resto (carga o confiabilidad).

Saludos

Anónimo dijo...

0/0 = Infinito, no determinado, esta mal la formula para mi gusto, esa parte no tiende a cero.

Anónimo dijo...

0/0 tiende a infinito pero es indeterminado amigo

Publicar un comentario