En esta segunda parte del artículo veremos cómo configurar protocolos de enrutamiento dinámicos utilizando EIGRP para aprovechar todo el potencial de DMVPN y de esta manera lograr conectividad entre las redes Lan de las distintas sucursales o Spokes.

Configurando EIGRP

Partiremos configurando los Spokes.

Spoke 1:

Se levanta el proceso EIGRP 100 y se añaden las ip al proceso:

Se repite el proceso en Spoke 2: hasta aquí nada distinto a lo ya acostumbrado.


Ahora configuremos EIGRP en el HUB. Recuerde desactivar Split Horizon, caso contrario tendremos problemas.


Observe como se forman las adyacencias con los Spokes. Miremos la tabla de vecinos en el HUB:


Miremos tabla de enrutamiento en los spokes:


Ahora veamos la tabla de enrutamiento con más detalle en Spoke 1. En el Spoke 2 tendríamos casi lo mismo donde lo importante es identificar el origen de las rutas que en este caso apunta a la dirección del HUB 172.16.0.3.


Podemos determinar que las rutas aprendidas siempre se publican desde del HUB por ende el camino del tráfico será siempre a través del Hub. Comprobemos esto:


Observemos que el ping tiene éxito y el camino que toma es a través del HUB o R1.

Esto podría no ser práctico en el caso que tengamos muchas sucursales, es por eso que ingresaremos un comando para que la ruta anunciada entre Spokes no sea el HUB.

Para esto entramos a la interfaz túnel del R4, que es el Hub, y hacemos lo siguiente:

Como se puede observar el proceso de EIGRP descubre que existe un cambio en la forma de publicar la ruta entendiendo que ya no se utiliza la ip de la interfaz del tunnel de R4 sino más bien la del origen de la ruta. Esto lo podemos comprobar de la siguiente manera:

Finalmente haremos pruebas de conectividad para comprobar por donde se va el tráfico:


Nótese que ahora el tráfico no pasa por el hub sino que va directo al spoke 2. En definitiva esto es lo que se quería lograr. Esta parte de la configuración se le denomina DMVPN fase 2.

Una 3era fase consiste en publicar rutas sumarizadas o rutas por defecto hacia los spokes con el objetivo de reducir el tamaño de la tabla de enrutamiento (imaginen tener 100 sucursales o más). Al hacer esto nuevamente se genera la problemática que el tráfico es anunciado siempre desde el hub y en consecuencia todo el tráfico será a través del HUB.

Para resolver este problema se apela nuevamente a NHRP donde en las interfaces tunnel del hub escribimos: ip nhrp redirect y en las interfaces túnel de los spoke: ip nhrp shorcut.

Esto tendrá como consecuencia que NHRP pondrá en la tabla de ruteo entradas específicas para que los spokes tengan tráfico directo.

En el próximo capítulo veremos como se configura DMVPN con OSPF.

No duden en utilizar la sección de comentarios para hacernos llegar dudas y preguntas.