EIGRP-naboer kommer ikke op på DMVPN-overlayet

Tunnelen er oppe, én spoke kan pinge en anden, og EIGRP viser stadig ingen nabo på hubben. Den kombination er normal og ikke mystisk: et ping beviser unicast-rækkevidde gennem NHRP, og EIGRP-hellos er multicast. På et DMVPN-overlay er routingprotokollens leveringsmodel en anden konfigurationsflade, og den springer folk over, fordi den første flade allerede ser sund ud. Hvert lag nedenunder kontrolleres med sin egen kommando, så en fejl i ét lag sender dig ikke tilbage til toppen af listen.

Skriv de nabo-forhold ned, du forventer

Inden enhver show-kommando skal du lave en kort liste: hvilken spoke skal peer med hvilken hub, over hvilken tunnelinterface, i hvilket EIGRP-autonome system. Design med flere hubs fejler i hullerne mellem hubs, og en liste forvandler “EIGRP er i stykker” til “spoke 3 registrerer sig ikke hos hub 2”. Medtag de tunnelsubnet, du forventer på hvert link, fordi uoverensstemmelse mellem adresserne i de to ender ser præcis ud som en protokolfejl. Skriv listen i ticketen, så næste vagt sammenligner med designet i stedet for med det sidste skærmbillede.

Kontroller NHRP, derefter multicast-stien

Start med registreringstilstand og de mappings, som hubben faktisk holder. En spoke uden dynamisk post på hubben er ikke registreret, og ingen routingprotokol retter det. Bekræft derefter, at spoken accepterer multicast fra hubbens NBMA-adresse, hvilket er en separat linje fra NHS-posten.

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

Det er linjen ip nhrp map multicast, der lader spoken sende sine hellos til hubben som replikeret multicast over overlayet, og som lader hubbens multicast nå de spokes, den har registreret. Uden den virker unicast gennem NHRP, og multicast gør ikke, og det er præcis den opdeling, der får et ping til at ligne et bevis. Ciscos IOS XE DMVPN-guide dokumenterer multicast-adfærden for hub og spokes for hver fase, så tilpas din konfiguration til den fase, du faktisk har udrullet, i stedet for at kopiere et fragment fra en anden topologi.

Kontroller EIGRPs egen interfacepolitik

En tunnel, der ikke er i EIGRP-processen eller er passive, danner aldrig et nabo-forhold, uanset hvor sundt overlayet er. Læs interfacets deltagelse og nabo-tabellen sammen, fordi det første forklarer det andet.

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

Autentificering og metrikvægte skal stemme i begge ender. En nøglekæde med forkert tilstand, eller uoverensstemmelse i K-værdien, dropper hellos uden en tydelig syslog-linje hos modtageren. Hvis designet bruger eksplicit konfigurerede unicast-naboer, så følg den model fuldt ud i stedet for at lægge den oven på multicast-indstillinger, indtil noget kommer op.

Hold GRE-transport og IPsec-beskyttelse adskilt

DMVPN transporterer multicast inde i GRE, og IPsec beskytter GRE-pakkerne frem for den indre multicast direkte. Derfor er den generelle påstand, at IPsec ikke kan transportere multicast, forkert for dette design og ubrugelig som diagnose. Kontroller IPsec-profilen på tunnelen, sikkerhedsassociationerne for hver peer og tunnelinterfacets tilstand som tre separate fakta.

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

En SA, der er oppe med tællere, der bevæger sig, mens EIGRP bliver nede, flytter din undersøgelse tilbage op i stakken: pakkerne bliver beskyttet og leveret, så problemet er, hvilke pakker protokollen vælger at sende.

Verificer ruter, ikke kun nabo-antal

Når nabo-forholdet er dannet, så læs, hvad det annoncerer og installerer. På en multipoint-tunnel afgør split horizon og next-hop-adfærd, om en spoke kan nå en anden spoke gennem hubben, og summering kan skjule et prefix, selv om nabo-forholdet er perfekt.

Slut af med en tilladt applikation mellem to sites og bekræft den sti, den tager. Direkte spoke-til-spoke-genveje er et videresendelseskrav med deres egen NHRP- og sikkerhedstilstand, og at tilføje dem for at få nabo-antallet til at se bedre ud skaber normalt et andet problem.

Skriv det fasedelte design, multicast-mappingen og EIGRP-politikken ned ét sted. Den næste ingeniør får brug for designet, ikke transskriptionen.