¿Vecino EIGRP o tránsito DMVPN? Comprueba primero el rol

Falta la adyacencia y el router del medio parece el sospechoso obvio. Puede ser inocente. Reenviar los paquetes externos del túnel y participar en el protocolo de enrutamiento overlay son dos trabajos distintos, y un equipo puede hacer el primero sin hacer el segundo. Realiza las cinco comprobaciones siguientes en orden y detente en la primera que falle.

Paso 1: dibuja los dos roles

Dibuja la adyacencia EIGRP prevista como una conexión lógica entre dos routers y, después, dibuja los routers underlay que transportan sus paquetes de túnel. El mismo equipo no tiene que aparecer en ambas listas, y confundir las listas es la razón más habitual de que se acuse a un router de tránsito sano de romper la adyacencia.

Un router de tránsito reenvía los paquetes externos con su enrutamiento IP y su política habituales. No necesita ejecutar el protocolo que viaja dentro del túnel protegido ni necesita un proceso EIGRP para hacer pasar esos paquetes.

Paso 2: comprueba qué termina el dispositivo del medio

Si el router del medio termina el túnel y debe formar adyacencias EIGRP con los spoke, la respuesta cambia por completo. Ese equipo necesita el comportamiento de enrutamiento overlay admitido, y llamarlo tránsito no hace desaparecer el requisito de vecino. Lee la configuración del túnel antes que la del enrutamiento. Esa respuesta decide todas las comprobaciones que siguen.

Así que la primera pregunta real no es qué protocolo ajustar. Es si la caja es un hub, un spoke, un simple salto underlay o un servicio Layer 2 que transporta tramas entre extremos.

Paso 3: verifica el plano de control del vecino

En cada equipo que deba ser vecino, confirma cuatro cosas: la instancia EIGRP y el número de sistema autónomo, los parámetros de autenticación, la interfaz que participa en el proceso y la sentencia de red que cubre esa interfaz. Un desajuste en cualquiera de ellas mantiene la adyacencia caída mientras la interfaz sigue activa y el ping sigue funcionando.

El RFC 7868 describe EIGRP como un protocolo IP con un intercambio de control por multicast, y por eso una relación de vecindad no es algo que un router intermedio pueda suplir enrutando paquetes hacia un destino. O el intercambio de control llega al par, o la adyacencia no se forma.

Paso 4: verifica que el transporte entrega el intercambio de control

A continuación, comprueba que el overlay transporta realmente el tráfico de control entre los extremos previstos. Inspecciona el mapeo NHRP del par y la ruta externa que llega hasta él, y luego confirma que la interfaz del túnel está activa y deja pasar tráfico. Un ping underlay correcto demuestra que el camino externo existe; no demuestra que se haya entregado el intercambio de control del overlay.

Un servicio Layer 2 transparente, un túnel punto a punto y una nube DMVPN multipunto entregan el multicast de formas distintas. Sigue el modelo de interfaz, NHRP y multicast admitido para el que realmente está desplegado en lugar de suponer que los tres se comportan igual.

Paso 5: rediseña la frontera si no puede participar

Si un equipo overlay necesario no puede ejecutar el protocolo, cambia el diseño de forma explícita. Usa un protocolo o modelo de intercambio admitido en esa frontera, o prepara un túnel de extremo a extremo adecuado para que los vecinos sean los extremos que realmente hablan entre sí. No supongas que una ruta estática convierte a un no participante en un relé para cada paquete de control.

Anota el rol de cada equipo en el diagrama y consérvalo junto con la configuración. El RFC 7868 define el intercambio de protocolo, y esa definición es la referencia de por qué la relación de vecindad no se puede simular con enrutamiento de tránsito.

Cuando la adyacencia sigue fallando después de las cinco comprobaciones, los sospechosos restantes son funciones de plataforma como el tratamiento del multicast en la interfaz del túnel y las políticas que filtran el protocolo 88. Son causas concretas y comprobables, y valen más que otra ronda de culpar al router del medio.