EIGRP-nabo eller DMVPN-transitt? Sjekk rollen først

Nabolaget mangler, og ruteren i midten ser ut som den åpenbare mistenkte. Den kan være uskyldig. Å videresende de ytre tunnelpakkene og å delta i overlay-rutingsprotokollen er to forskjellige jobber, og en enhet kan gjøre den første uten å gjøre den andre. Gå gjennom de fem kontrollene nedenfor i rekkefølge, og stopp ved den første som feiler.

Trinn 1: tegn de to rollene

Tegn det tiltenkte EIGRP-nabolaget som en logisk forbindelse mellom to rutere, og tegn deretter underlay-ruterne som bærer tunnelpakkene. Samme enhet trenger ikke stå på begge listene, og å blande listene er den vanligste grunnen til at en sunn transittruter blir beskyldt for å ødelegge nabolaget.

En transittruter videresender de ytre pakkene med sin vanlige IP-ruting og -politikk. Den trenger ikke kjøre protokollen som bæres inne i den beskyttede tunnelen, og den trenger ingen EIGRP-prosess for å sende pakkene videre.

Trinn 2: kontroller hva enheten i midten terminerer

Hvis ruteren i midten terminerer tunnelen og skal danne EIGRP-nabolag med spoke-enheter, endres svaret fullstendig. Den enheten trenger den støttede overlay-rutingsoppførselen, og å kalle den transitt fjerner ikke nabokravet. Les tunnelkonfigurasjonen før rutingskonfigurasjonen. Det svaret avgjør hver kontroll som følger.

Det første virkelige spørsmålet er altså ikke hvilken protokoll som skal justeres. Det er om boksen er en hub, en spoke, et rent underlay-hopp eller en Layer 2-tjeneste som bærer rammer mellom endepunkter.

Trinn 3: verifiser naboens kontrollplan

På hver enhet som skal være nabo, bekreft fire ting: EIGRP-forekomsten og nummeret til det autonome systemet, autentiseringsparameterne, grensesnittet som deltar i prosessen, og nettverkserklæringen som dekker grensesnittet. Avvik i én av dem holder nabolaget nede mens grensesnittet er oppe og ping fortsatt virker.

RFC 7868 beskriver EIGRP som en IP-protokoll med en multicast-kontrollutveksling, og derfor er et nabo-forhold ikke noe en mellomliggende ruter kan erstatte ved å rute pakker mot en destinasjon. Enten når kontrollutvekslingen frem til peeren, eller så dannes ikke nabolaget.

Trinn 4: verifiser at transporten leverer kontrollutvekslingen

Sjekk deretter om overlayet faktisk bærer kontrolltrafikken mellom de tiltenkte endepunktene. Undersøk NHRP-mappingen for peeren og den ytre ruten som når den, og bekreft deretter at tunnelgrensesnittet er oppe og slipper trafikk gjennom. En vellykket underlay-ping beviser at den ytre veien finnes; den beviser ikke at overlayets kontrollutveksling ble levert.

En gjennomsiktig Layer 2-tjeneste, en punkt-til-punkt-tunnel og en multipoint-DMVPN-sky leverer multicast ulikt. Følg den støttede grensesnitt-, NHRP- og multicast-modellen for den som faktisk er utrullet, i stedet for å anta at alle tre oppfører seg likt.

Trinn 5: redesign grensen hvis den ikke kan delta

Hvis en påkrevd overlay-enhet ikke kan kjøre protokollen, endre designet eksplisitt. Bruk en støttet protokoll eller utvekslingsmodell ved den grensen, eller sett opp en passende ende-til-ende-tunnel slik at naboene er endepunktene som faktisk snakker sammen. Ikke anta at en statisk rute gjør en ikke-deltaker om til et relay for hver kontrollpakke.

Noter rollen til hver enhet i diagrammet og oppbevar den sammen med konfigurasjonen. RFC 7868-definisjonen av protokollutvekslingen er referansen for hvorfor nabo-forholdet ikke kan simuleres med transitt-videresending.

Når nabolaget fortsatt feiler etter alle fem kontrollene, er de gjenstående mistenkte plattformfunksjoner som multicast-håndtering på tunnelgrensesnittet og politikk som filtrerer protokoll 88. Det er konkrete, testbare årsaker, og de er mer verdt enn nok en runde med å gi ruteren i midten skylden.