EIGRP-grannar kommer inte upp på DMVPN-overlayen

Tunneln är uppe, en spoke kan pinga en annan, och EIGRP visar fortfarande ingen granne på hubben. Den kombinationen är normal och inte mystisk: ett ping bevisar unicast-nåbarhet genom NHRP, och EIGRP:s hello är multicast. På en DMVPN-overlay är routingprotokollets leveransmodell en andra konfigurationsyta, och det är just den folk hoppar över eftersom den första ytan redan ser frisk ut. Varje lager nedanför kontrolleras med sitt eget kommando, så ett fel i ett lager skickar dig inte tillbaka till toppen av listan.

Skriv ner de grannskap du förväntar dig

Innan något show-kommando, gör en kort lista: vilken spoke som ska peera med vilken hub, över vilket tunnelgränssnitt och i vilket autonomt EIGRP-system. Designer med flera hubbar misslyckas i luckorna mellan hubbarna, och en lista förvandlar ”EIGRP är trasigt” till ”spoke 3 registrerar sig inte hos hub 2”. Ta med de tunnelsubnät du förväntar dig på varje länk, eftersom en adresskillnad mellan de två ändarna ser exakt ut som ett protokollfel. Skriv listan i ärendet, så att nästa skift jämför med designen och inte med den senaste skärmbilden.

Kontrollera NHRP, sedan multicast-vägen

Börja med registreringsstatus och de mappningar som hubben faktiskt håller. En spoke utan dynamisk post på hubben är inte registrerad, och inget routingprotokoll rättar det. Bekräfta sedan att spoken tar emot multicast från hubbens NBMA-adress, vilket är en egen rad från 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 är raden ip nhrp map multicast som låter spoken skicka sina hello till hubben som replikerad multicast över overlayen, och som låter hubbens multicast nå de spokes den har registrerat. Utan den fungerar unicast genom NHRP men inte multicast, och det är just den delningen som får ett ping att se ut som ett bevis. Ciscons IOS XE DMVPN-guide dokumenterar multicast-beteendet för hubb och spokes för varje fas, så anpassa konfigurationen till den fas du faktiskt rullade ut i stället för att kopiera ett fragment från en annan topologi.

Kontrollera EIGRP:s egen gränssnittspolicy

En tunnel som inte ligger i EIGRP-processen, eller som är passive, bildar aldrig ett grannskap, hur frisk overlayen än är. Läs gränssnittets deltagande och grannbordet tillsammans, eftersom det första förklarar det andra.

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 och metrikvikter måste stämma i båda ändar. En nyckelkedja med fel läge, eller en avvikelse i K-värdet, tappar hello utan en tydlig syslog-rad hos mottagaren. Om designen använder explicit konfigurerade unicast-grannar ska du följa den modellen fullt ut i stället för att lägga den ovanpå multicast-inställningarna tills något kommer upp.

Håll GRE-transport och IPsec-skydd åtskilda

DMVPN transporterar multicast inuti GRE, och IPsec skyddar GRE-paketen och inte den inre multicast-trafiken direkt. Därför är det allmänna påståendet att IPsec inte kan transportera multicast fel för den här designen och oanvändbart som diagnos. Kontrollera IPsec-profilen på tunneln, säkerhetsassociationerna för varje peer och tunnelgränssnittets tillstånd som tre separata fakta.

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

En SA som är uppe med räknare som rör sig medan EIGRP ligger kvar nere flyttar utredningen tillbaka upp i stacken: paketen skyddas och levereras, så problemet är vilka paket protokollet väljer att skicka.

Verifiera rutter, inte bara antal grannar

När grannskapet är format, läs vad det annonserar och installerar. På en multipoint-tunnel avgör split horizon och next-hop-beteende om en spoke kan nå en annan spoke via hubben, och sammanfattning kan dölja ett prefix även om granntillståndet är perfekt.

Avsluta med en tillåten applikation mellan två platser och bekräfta den väg den tar. Direkta spoke-till-spoke-genvägar är ett vidarebefordringskrav med egen NHRP- och säkerhetsstatus, och att lägga till dem för att få grannantalet att se bättre ut skapar oftast ett andra problem.

Skriv ner den fasindelade designen, multicast-mappningen och EIGRP-policyn på ett ställe. Nästa ingenjör behöver designen, inte transkriptionen.