Os veciños EIGRP non levantan no superposto DMVPN

O unicast sobre o superposto funciona e a adxacencia segue fallando, así que revise a replicación multicast de NHRP, a política EIGRP do túnel e IPsec como tres capas separadas.

O túnel está levantado, un spoke pode facer ping a outro e EIGRP segue sen mostrar ningún veciño no hub. Esa combinación é normal, non misteriosa: un ping demostra alcanzabilidade unicast a través de NHRP, e os hello de EIGRP son multicast. Nun superposto DMVPN o modelo de entrega do protocolo de encamiñamento é unha segunda superficie de configuración, e é xustamente a que a xente evita porque a primeira superficie xa parece san. Cada capa de abaixo compróbase co seu propio comando, así que un fallo nunha non o devolve ao principio da lista.

Anote as adxacencias que espera

Antes de calquera comando show, faga unha lista curta: que spoke debe emparellarse con que hub, por que interface de túnel e en que sistema autónomo EIGRP. Os deseños con varios hubs fallan nos ocos entre hubs, e unha lista converte «EIGRP está roto» en «o spoke 3 non se rexistra no hub 2». Inclúa as subredes de túnel que espera en cada enlace, porque unha discrepancia de enderezos entre os dous extremos parece exactamente un fallo de protocolo. Escriba a lista no ticket, para que a seguinte quenda compare co deseño e non coa última captura de pantalla.

Revise NHRP e despois a ruta multicast

Empece polo estado de rexistro e os mapeos que o hub realmente mantén. Un spoke sen entrada dinámica no hub non se rexistrou, e ningún protocolo de encamiñamento o arranxará. Despois confirme que o spoke acepta multicast desde o enderezo NBMA do hub, que é unha liña distinta da 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

A liña ip nhrp map multicast é a que permite ao spoke enviar os seus hello ao hub como multicast replicado sobre o superposto, e a que permite que o multicast do hub chegue aos spokes que ten rexistrados. Sen ela, o unicast por NHRP funciona e o multicast non, e esa é precisamente a división que fai que un ping pareza unha proba. A guía de Cisco IOS XE DMVPN documenta o comportamento multicast do hub e dos spokes para cada fase, así que axuste a súa configuración á fase que realmente despregou en lugar de copiar un fragmento doutra topoloxía.

Revise a política de interface propia de EIGRP

Un túnel que non está no proceso EIGRP, ou que é passive, nunca formará unha adxacencia por moi san que estea o superposto. Lea a participación da interface e a táboa de veciños xuntas, porque a primeira explica a 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

A autenticación e os pesos de métrica teñen que coincidir nos dous extremos. Unha cadea de claves co modo equivocado, ou unha discrepancia no valor K, descarta os hello sen unha liña syslog evidente no receptor. Se o deseño usa veciños unicast configurados explicitamente, siga ese modelo por completo en lugar de apilalo sobre a configuración multicast ata que algo levante.

Manteña o transporte GRE e a protección IPsec por separado

DMVPN transporta multicast dentro de GRE, e IPsec protexe os paquetes GRE e non o multicast interno directamente. Por iso a afirmación xeral de que IPsec non pode transportar multicast é incorrecta para este deseño e inútil como diagnóstico. Revise o perfil IPsec do túnel, as asociacións de seguridade de cada peer e o estado da interface de túnel como tres feitos separados.

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

Unha SA levantada con contadores que avanzan mentres EIGRP segue abaixo devolve a súa investigación cara arriba da pila: os paquetes protéxense e entréganse, así que o problema é que paquetes escolle enviar o protocolo.

Verifique rutas, non só o número de veciños

Cando se forme a adxacencia, lea que anuncia e instala. Nun túnel multipunto, o split horizon e o comportamento do seguinte salto deciden se un spoke pode alcanzar outro a través do hub, e a summarización pode ocultar un prefixo aínda que a relación de veciñanza sexa perfecta.

Termine cunha aplicación permitida entre dúas sedes e confirme a ruta que toma. Os atallos directos spoke a spoke son un requisito de reenvío co seu propio estado NHRP e de seguridade, e engadilos para que o número de veciños pareza mellor adoita crear un segundo problema.

Rexistre o deseño por fases, o mapeo multicast e a política EIGRP nun só sitio. O seguinte enxeñeiro necesitará o deseño, non a transcrición.

Artigos relacionados