Los vecinos EIGRP no levantan en el superpuesto DMVPN

El túnel está levantado, un spoke puede hacer ping a otro y EIGRP sigue sin mostrar ningún vecino en el hub. Esa combinación es normal, no misteriosa: un ping demuestra alcanzabilidad unicast a través de NHRP, y los hello de EIGRP son multicast. En un superpuesto DMVPN el modelo de entrega del protocolo de enrutamiento es una segunda superficie de configuración, y es justo la que la gente se salta porque la primera superficie ya parece sana. Cada capa de abajo se comprueba con su propio comando, así que un fallo en una no le devuelve al principio de la lista.

Anote las adyacencias que espera

Antes de cualquier comando show, haga una lista corta: qué spoke debe emparejarse con qué hub, por qué interfaz de túnel y en qué sistema autónomo EIGRP. Los diseños con varios hubs fallan en los huecos entre hubs, y una lista convierte «EIGRP está roto» en «el spoke 3 no se registra en el hub 2». Incluya las subredes de túnel que espera en cada enlace, porque una discrepancia de direcciones entre los dos extremos parece exactamente un fallo de protocolo. Escriba la lista en el ticket, para que el siguiente turno compare con el diseño y no con la última captura de pantalla.

Revise NHRP y después la ruta multicast

Empiece por el estado de registro y los mapeos que el hub realmente mantiene. Un spoke sin entrada dinámica en el hub no se ha registrado, y ningún protocolo de enrutamiento lo arreglará. Después confirme que el spoke acepta multicast desde la dirección NBMA del hub, que es una línea distinta de la entrada NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

La línea ip nhrp map multicast es la que permite al spoke enviar sus hello al hub como multicast replicado sobre el superpuesto, y la que permite que el multicast del hub llegue a los spokes que tiene registrados. Sin ella, el unicast por NHRP funciona y el multicast no, y esa es precisamente la división que hace que un ping parezca una prueba. La guía de Cisco IOS XE DMVPN documenta el comportamiento multicast del hub y de los spokes para cada fase, así que ajuste su configuración a la fase que realmente desplegó en lugar de copiar un fragmento de otra topología.

Revise la política de interfaz propia de EIGRP

Un túnel que no está en el proceso EIGRP, o que es passive, nunca formará una adyacencia por muy sano que esté el superpuesto. Lea la participación de la interfaz y la tabla de vecinos juntas, porque la primera explica la segunda.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

La autenticación y los pesos de métrica tienen que coincidir en ambos extremos. Una cadena de claves con el modo equivocado, o una discrepancia en el valor K, descarta los hello sin una línea syslog evidente en el receptor. Si el diseño usa vecinos unicast configurados explícitamente, siga ese modelo por completo en lugar de apilarlo sobre la configuración multicast hasta que algo levante.

Mantenga el transporte GRE y la protección IPsec por separado

DMVPN transporta multicast dentro de GRE, e IPsec protege los paquetes GRE y no el multicast interno directamente. Por eso la afirmación general de que IPsec no puede transportar multicast es incorrecta para este diseño e inútil como diagnóstico. Revise el perfil IPsec del túnel, las asociaciones de seguridad de cada peer y el estado de la interfaz de túnel como tres hechos separados.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

Una SA levantada con contadores que avanzan mientras EIGRP sigue abajo devuelve su investigación hacia arriba de la pila: los paquetes se protegen y se entregan, así que el problema es qué paquetes elige enviar el protocolo.

Verifique rutas, no solo el número de vecinos

Cuando se forme la adyacencia, lea qué anuncia e instala. En un túnel multipunto, el split horizon y el comportamiento del siguiente salto deciden si un spoke puede alcanzar a otro a través del hub, y la summarización puede ocultar un prefijo aunque la relación de vecindad sea perfecta.

Termine con una aplicación permitida entre dos sedes y confirme la ruta que toma. Los atajos directos spoke a spoke son un requisito de reenvío con su propio estado NHRP y de seguridad, y añadirlos para que el número de vecinos parezca mejor suele crear un segundo problema.

Registre el diseño por fases, el mapeo multicast y la política EIGRP en un solo sitio. El siguiente ingeniero necesitará el diseño, no la transcripción.