EIGRP-naboer kommer ikke opp på DMVPN-overlayet

Tunnelen er oppe, én spoke kan pinge en annen, og EIGRP viser fortsatt ingen nabo på huben. Den kombinasjonen er normal og ikke mystisk: en ping beviser unicast-nåbarhet gjennom NHRP, og EIGRP-helloer er multicast. På et DMVPN-overlay er ruteprotokollens leveringsmodell en andre konfigurasjonsflate, og det er den folk hopper over fordi den første flaten allerede ser sunn ut. Hvert lag nedenfor kontrolleres med sin egen kommando, så en feil i ett lag sender deg ikke tilbake til toppen av listen.

Skriv ned nabo-forholdene du forventer

Før enhver show-kommando, lag en kort liste: hvilken spoke skal peere med hvilken hub, over hvilket tunnelgrensesnitt, i hvilket autonome EIGRP-system. Design med flere huber feiler i hullene mellom hubene, og en liste gjør «EIGRP er ødelagt» om til «spoke 3 registrerer seg ikke hos hub 2». Ta med tunnel-subnettene du forventer på hver lenke, fordi en adresseuoverensstemmelse mellom de to endene ser nøyaktig ut som en protokollfeil. Skriv listen i billetten, slik at neste skift sammenligner med designet og ikke med det siste skjermbildet.

Kontroller NHRP, deretter multicast-stien

Start med registreringstilstand og tilordningene huben faktisk holder. En spoke uten dynamisk oppføring på huben er ikke registrert, og ingen ruteprotokoll retter det. Bekreft deretter at spoken godtar multicast fra hubens NBMA-adresse, som er en egen linje fra NHS-oppføringen.

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 som lar spoken sende helloene sine til huben som replikert multicast over overlayet, og som lar hubens multicast nå de spokene den har registrert. Uten den virker unicast gjennom NHRP og multicast gjør det ikke, og det er nettopp denne delingen som får en ping til å se ut som et bevis. Ciscons IOS XE DMVPN-veiledning dokumenterer multicast-atferden til hub og spoke for hver fase, så tilpass konfigurasjonen til fasen du faktisk rullet ut, i stedet for å kopiere et fragment fra en annen topologi.

Kontroller EIGRPs egen grensesnittpolicy

En tunnel som ikke er i EIGRP-prosessen, eller som er passive, danner aldri et nabo-forhold, uansett hvor sunn overlayet er. Les grensesnittets deltakelse og nabotabellen sammen, fordi det første forklarer det andre.

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

Autentisering og metrikkvekter må stemme i begge ender. En nøkkelkjede med feil modus, eller uoverensstemmelse i K-verdien, slipper helloer uten en tydelig syslog-linje hos mottakeren. Hvis designet bruker eksplisitt konfigurerte unicast-naboer, følg den modellen fullt ut i stedet for å legge den oppå multicast-innstillingene til noe kommer opp.

Hold GRE-transport og IPsec-beskyttelse adskilt

DMVPN frakter multicast inne i GRE, og IPsec beskytter GRE-pakkene i stedet for den indre multicast direkte. Derfor er den generelle påstanden om at IPsec ikke kan frakte multicast feil for dette designet og ubrukelig som diagnose. Kontroller IPsec-profilen på tunnelen, sikkerhetsassosiasjonene for hver peer og tilstanden til tunnelgrensesnittet 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 som er oppe med tellere som beveger seg mens EIGRP blir nede, flytter undersøkelsen tilbake opp i stakken: pakkene beskyttes og leveres, så problemet er hvilke pakker protokollen velger å sende.

Verifiser ruter, ikke bare nabo-antall

Når nabo-forholdet er dannet, les hva det annonserer og installerer. På en multipoint-tunnel avgjør split horizon og next-hop-atferd om en spoke kan nå en annen spoke gjennom huben, og oppsummering kan skjule et prefiks selv om nabo-forholdet er perfekt.

Avslutt med en tillatt applikasjon mellom to nettsteder og bekreft stien den tar. Direkte spoke-til-spoke-snarveier er et videresendingskrav med sin egen NHRP- og sikkerhetstilstand, og å legge dem til for å få naboantallet til å se bedre ut skaper vanligvis et andre problem.

Skriv ned det fasedelte designet, multicast-tilordningen og EIGRP-policyen på ett sted. Den neste ingeniøren trenger designet, ikke transkripsjonen.