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.
No hay comentarios:
Publicar un comentario