TH-LAB MISIÓN#2 - MANIPULACIÓN DE RUTAS y BALANCEO DE CARGA - EIGRP.

Escenario

La empresa TH-LAB está planeando optimizar la red WAN Empresarial para mejorar su rendimiento y robustecer la infraestructura, como Ingeniero de redes Jr. recibes peticiones de los ingenieros Sr para llevar a cabo poco a poco el proyecto.

Nota: TH-LAB cuenta con 5 sitios remotos (S1-S5) y una red Backbone (R1-R4). EIGRP Name mode es utilizado en toda la infraestructura.

Misión #2

Como ingeniero de Redes Jr. en TH-LAB, tu misión es asegurar que cualquier tráfico de origen sitio S2 (192.168.252.2) hacia S4 (192.168.254.4) haga balanceo de carga entre R4 y R3.

Nota: No se debe cambiar el Delay y Bandwidth de las interfaces en ninguna circunstancia.

Posible solución

Como buenas prácticas antes de hacer cualquier maniobra en la red lo primero que debemos hacer es revisar el comportamiento del tráfico actual.

Como se puede observar en la topología física, R2 tiene 2 caminos para llegar a R4, pero también sabemos que a nivel EIGRP ciertas condiciones se deben cumplir para considerar una de las rutas como secundaria o hasta llegar a ser un punto para realizar balanceo.

Revisando la tabla de enrutamiento, podemos ver R2 está usando únicamente el camino hacia R4 para enviar tráfico, lo que es totalmente lógico ya que es la mejor ruta, ¿pero está considerando el segundo camino (R3) como respaldo? Revisaremos la tabla de topología de EIGRP.

Observamos que el 192.168.254.4 tiene solamente un sucesor (R4), eso nos indica que R3 no cumple con la condición de viabilidad de EIGRP y no se lo considera como ruta de respaldo. Enseguida confirmamos esa teoría (agregando all-links al comando anterior se puede ver todas las rutas incluyendo a las que fueron descartadas).

Ahora si Podemos observar el segundo camino, pero EIGRP no lo toma en cuenta porque no cumple con la condición de viabilidad, “para considerar una ruta como respaldo la distancia reportada (RD) por el vecino debe ser estrictamente menor a la métrica de la ruta primaria (FD)” en este caso el RD reportado por R3 es 2048000 y el FD también es igual 2048000, son iguales, R3 no cumple, EIGRP descarta la ruta.

¿Entonces como cumplir con la misión?

Hay 2 posibilidades para que EIGRP realice balanceo de cargar, ambas rutas deben tener la misma métrica y por ende se colocan ambas rutas en la tabla de ruteo (ECMP - Equal Cost Multi-path) o en caso de que las métricas no son iguales y la segunda ruta cumple con la condición de viabilidad (es respaldo) se puede configurar una varianza para permitir que la ruta de respaldo pueda instalarse en la tabla de ruteo (uECMP- unequal Cost Multi-path).

Ya vimos que ni siquiera tenemos una ruta de respaldo, vamos a tener que manipular las métricas para evitar que la ruta por R3 no sea descartada por EIGRP en R2. Sabemos que EIGRP por defecto usa Delay y bandwidth para calcular las métricas, podríamos cambiar algunos de estos valores en las interfaces para lograr nuestro objetivo, pero primero fue restringida en la misión y además no es la mejor solución porque afectaría todas las demás rutas que cruzan esas interfaces o incluso puede llegar a comprometer el funcionamiento o uso de otros protocolos de enrutamiento.

Para escenarios similares EIGRP tiene un mecanismo especial que se conocen como Offset-lists, permiten modificar la métrica de una ruta en particular sin necesidad de hacer cambios en las interfaces.

1- ACL

ip access-list standard S4
 permit 192.168.254.4
 exit

2- OFFSET-LIST

router eigrp th-lab
 !
 address-family ipv4 unicast autonomous-system 180
  !
  topology base
   offset-list S4 in 1000 GigabitEthernet0/1
  exit-af-topology

Durante nuestro análisis habíamos visto que la distancia reportada (RD) de R3 era igual a la métrica de la mejor ruta (FD) por eso no se tomó en cuenta como ruta respaldo, entonces aquí aumentamos ligeramente (de 1000) la FD para que la RD de R3 sea menor al FD y así logramos que la ruta por R3 aparezca en la tabla de topología como ruta de respaldo.

Ya tenemos una ruta de respaldo, pero todavía no podemos hacer balanceo porque solo la ruta principal está en tabla de ruteo, a continuación, vamos a hacer uso de una de las características principales de EIGRP, uECMP (unequal cost multi-path), que permite colocar tanto la ruta principal como la de respaldo en la tabla de ruteo. Para lograr eso se debe cumplir con una condición “para instalar una ruta de respaldo en la tabla de ruteo su métrica debe ser menor a la varianza de EIGRP (varianza de EIGRP= FD x Variance multiplier)”.

Es decir, FD ruta de respaldo < (FD ruta primaria X Variance multiplier), ¿por cuál valor podemos multiplicar 2049000 para que sea superior a 2703360? La manera más fácil de encontrarlo es dividiendo 2703360 por 2049000, nos da 1.32, y como se puede configurar únicamente valores enteros se redondea a 2.

Enseguida validamos nuestra teoría configurando una varianza de 2 en la instancia de EIGRP.

router eigrp th-lab
 address-family ipv4 unicast autonomous-system 180
 topology base
   variance 2
   offset-list S4 in 1000 GigabitEthernet0/1
   exit-af-topology

Verificación

Después de configurar la varianza se puede apreciar 2 rutas para el destino S4 en la tabla de enrutamiento, mismas que serán usadas para hacer balance de carga del tráfico hacia el destino.

Desde R4 se hace casi lo mismo para balancear el tráfico de regreso.

Creación del ACL

Configuración de la varianza y offset-list

VERIFICACIÓN

Con eso se completó la misión, garantizamos el balanceo de carga entre R3 y R4 para el trafico entre S2 y S4.

Para cualquier consulta o duda no duden en contactarme.