EIGRP-granne eller DMVPN-transit? Kontrollera rollen först

Grannskapet saknas, och routern i mitten ser ut som den självklara misstänkten. Den kan vara oskyldig. Att vidarebefordra de yttre tunnelpaketen och att delta i overlay-routingprotokollet är två olika jobb, och en enhet kan göra det första utan att göra det andra. Gå igenom de fem kontrollerna nedan i ordning och stanna vid den första som misslyckas.

Steg 1: rita de två rollerna

Rita det avsedda EIGRP-grannskapet som en logisk förbindelse mellan två routrar och rita sedan underlay-routrarna som bär dess tunnelpaket. Samma enhet behöver inte finnas i båda listorna, och att blanda ihop listorna är den vanligaste orsaken till att en frisk transitrouter anklagas för att bryta grannskapet.

En transitrouter vidarebefordrar de yttre paketen med sin vanliga IP-routing och -policy. Den behöver inte köra protokollet som bärs inne i den skyddade tunneln och behöver ingen EIGRP-process för att skicka vidare paketen.

Steg 2: kontrollera vad enheten i mitten avslutar

Om routern i mitten avslutar tunneln och ska bilda EIGRP-grannskap med spoke-enheter ändras svaret helt. Den enheten behöver det stödda overlay-routingbeteendet, och att kalla den transit tar inte bort grannekravet. Läs tunnelkonfigurationen före routingkonfigurationen. Det svaret avgör varje kontroll som följer.

Den första verkliga frågan är alltså inte vilket protokoll som ska justeras. Det är om lådan är en hub, en spoke, ett rent underlay-hopp eller en Layer 2-tjänst som bär ramar mellan ändpunkter.

Steg 3: verifiera grannens kontrollplan

Bekräfta fyra saker på varje enhet som ska vara granne: EIGRP-instansen och numret för det autonoma systemet, autentiseringsparametrarna, gränssnittet som deltar i processen och nätverksdeklarationen som täcker det gränssnittet. En avvikelse i någon av dem håller grannskapet nere medan gränssnittet är uppe och ping fortsätter att fungera.

RFC 7868 beskriver EIGRP som ett IP-protokoll med ett multicast-kontrollutbyte, och därför är en grannrelation inte något som en mellanliggande router kan ersätta genom att routa paket mot en destination. Antingen når kontrollutbytet peeren eller så bildas inte grannskapet.

Steg 4: verifiera att transporten levererar kontrollutbytet

Kontrollera sedan om overlayet faktiskt bär kontrolltrafiken mellan de avsedda ändpunkterna. Undersök NHRP-mappningen för peeren och den yttre vägen som når den, och bekräfta sedan att tunnelgränssnittet är uppe och släpper igenom trafik. En lyckad underlay-ping bevisar att den yttre vägen finns; den bevisar inte att overlayets kontrollutbyte levererades.

En transparent Layer 2-tjänst, en punkt-till-punkt-tunnel och ett multipoint-DMVPN-moln levererar multicast olika. Följ den stödda gränssnitts-, NHRP- och multicastmodellen för den som faktiskt är utrullad i stället för att anta att alla tre beter sig likadant.

Steg 5: gör om gränsen om den inte kan delta

Om en nödvändig overlay-enhet inte kan köra protokollet, ändra designen uttryckligen. Använd ett stött protokoll eller utbytesmodell vid den gränsen, eller ordna en lämplig ände-till-ände-tunnel så att grannarna är de ändpunkter som faktiskt talar med varandra. Anta inte att en statisk rutt gör en icke-deltagare till en relay för varje kontrollpaket.

Anteckna varje enhets roll i diagrammet och förvara den tillsammans med konfigurationen. RFC 7868-definitionen av protokollutbytet är referensen för varför grannrelationen inte kan simuleras med transit-vidarebefordran.

När grannskapet fortfarande misslyckas efter alla fem kontrollerna är de kvarvarande misstänkta plattformsfunktioner som multicast-hantering på tunnelgränssnittet och policy som filtrerar protokoll 88. Det är konkreta, testbara orsaker, och de är värda mer än ännu en runda där routern i mitten får skulden.