Els veïns EIGRP no arrenquen a la capa DMVPN

L’unicast per la capa funciona i l’adjacència continua fallant, així que reviseu la replicació multicast d’NHRP, la política EIGRP del túnel i IPsec com a tres capes separades.

El túnel està aixecat, un spoke pot fer ping a un altre i EIGRP continua sense mostrar cap veí al hub. Aquesta combinació és normal, no pas misteriosa: un ping demostra abastabilitat unicast a través d’NHRP, i els hello d’EIGRP són multicast. En una capa DMVPN el model de lliurament del protocol d’encaminament és una segona superfície de configuració, i és la que la gent s’estalvia perquè la primera superfície ja sembla sana. Cada capa de sota es comprova amb la seva pròpia ordre, de manera que un fallo en una no us torna al principi de la llista.

Anoteu les adjacències que espereu

Abans de qualsevol ordre show, feu una llista curta: quin spoke ha d’emparellar-se amb quin hub, per quina interfície de túnel i en quin sistema autònom EIGRP. Els dissenys amb diversos hubs fallen en els buits entre hubs, i una llista converteix «EIGRP està trencat» en «el spoke 3 no es registra al hub 2». Incloeu les subxarxes de túnel que espereu a cada enllaç, perquè una discrepància d’adreces entre els dos extrems sembla exactament un fallo de protocol. Escriviu la llista al tiquet, perquè el torn següent compari amb el disseny i no amb la darrera captura de pantalla.

Reviseu NHRP i després el camí multicast

Comenceu per l’estat de registre i els mapatges que el hub realment té. Un spoke sense entrada dinàmica al hub no s’ha registrat, i cap protocol d’encaminament ho arreglarà. Després confirmeu que el spoke accepta multicast de l’adreça NBMA del hub, que és una línia separada de l’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ínia ip nhrp map multicast és la que permet al spoke enviar els seus hello al hub com a multicast replicat per la capa, i la que permet que el multicast del hub arribi als spokes que té registrats. Sense ella, l’unicast per NHRP funciona i el multicast no, i aquesta és precisament la divisió que fa que un ping sembli una prova. La guia de Cisco IOS XE DMVPN documenta el comportament multicast del hub i dels spokes per a cada fase, així que ajusteu la vostra configuració a la fase que heu desplegat realment en lloc de copiar un fragment d’una altra topologia.

Reviseu la política d’interfície pròpia d’EIGRP

Un túnel que no és al procés EIGRP, o que és passive, no formarà mai una adjacència per molt sana que estigui la capa. Llegiu la participació de la interfície i la taula de veïns alhora, perquè la primera explica la segona.

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

L’autenticació i els pesos de mètrica han de coincidir als dos extrems. Una cadena de claus amb el mode equivocat, o una discrepància en el valor K, descarta els hello sense una línia syslog òbvia al receptor. Si el disseny fa servir veïns unicast configurats explícitament, seguiu aquell model completament en lloc d’apilar-lo sobre la configuració multicast fins que aparegui alguna cosa.

Manteniu el transport GRE i la protecció IPsec per separat

DMVPN transporta multicast dins de GRE, i IPsec protegeix els paquets GRE i no el multicast intern directament. Per això l’afirmació general que IPsec no pot transportar multicast és incorrecta per a aquest disseny i inútil com a diagnòstic. Reviseu el perfil IPsec del túnel, les associacions de seguretat de cada peer i l’estat de la interfície de túnel com a tres fets separats.

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

Una SA aixecada amb comptadors que avancen mentre EIGRP continua baix torna la vostra investigació cap amunt de la pila: els paquets es protegeixen i es lliuren, així que el problema és quins paquets el protocol tria enviar.

Verifiqueu les rutes, no només el nombre de veïns

Quan es forma l’adjacència, llegiu què anuncia i instal·la. En un túnel multipunt, l’split horizon i el comportament del següent salt decideixen si un spoke pot arribar a un altre a través del hub, i la summarització pot amagar un prefix encara que la relació de veïnatge sigui perfecta.

Acabeu amb una aplicació permesa entre dos llocs i confirmeu el camí que segueix. Les dreceres directes spoke-to-spoke són un requisit d’enviament amb el seu propi estat NHRP i de seguretat, i afegir-les per fer que el recompte de veïns sembli millor normalment crea un segon problema.

Registreu el disseny per fases, el mapatge multicast i la política EIGRP en un sol lloc. El proper enginyer necessitarà el disseny, no la transcripció.

Articles relacionats