EIGRP-nabo eller DMVPN-transit? Tjek rollen først

Naboskabet mangler, og routeren i midten ser ud som den oplagte mistænkte. Den kan være uskyldig. At videresende de ydre tunnelpakker og at deltage i overlay-routingprotokollen er to forskellige opgaver, og en enhed kan udføre den første uden at udføre den anden. Gå de fem kontroller nedenfor igennem i rækkefølge, og stop ved den første, der fejler.

Trin 1: tegn de to roller

Tegn det tilsigtede EIGRP-naboskab som en logisk forbindelse mellem to routere, og tegn derefter de underlay-routere, der bærer dets tunnelpakker. Den samme enhed behøver ikke optræde på begge lister, og forveksling af listerne er den hyppigste grund til, at en sund transitrouter beskyldes for at ødelægge naboskabet.

En transitrouter videresender de ydre pakker med sin almindelige IP-routing og -politik. Den behøver ikke køre den protokol, der bæres inde i den beskyttede tunnel, og den har ikke brug for en EIGRP-proces for at sende pakkerne videre.

Trin 2: tjek, hvad enheden i midten terminerer

Hvis routeren i midten terminerer tunnelen og skal danne EIGRP-naboskaber med spoke-enheder, ændrer svaret sig fuldstændigt. Den enhed har brug for den understøttede overlay-routingadfærd, og at kalde den transit fjerner ikke nabokravet. Læs tunnelkonfigurationen før routingkonfigurationen. Det svar afgør hver efterfølgende kontrol.

Det første reelle spørgsmål er altså ikke, hvilken protokol der skal justeres. Det er, om boksen er en hub, en spoke, et rent underlay-hop eller en Layer 2-tjeneste, der bærer rammer mellem endepunkter.

Trin 3: verificér naboens kontrolplan

På hver enhed, der skal være nabo, skal du bekræfte fire ting: EIGRP-instansen og det autonome systemnummer, godkendelsesparametrene, det interface der deltager i processen, og den netværkserklæring, der dækker det interface. Uoverensstemmelse i bare én af dem holder naboskabet nede, mens interfacet forbliver oppe, og ping fortsat virker.

RFC 7868 beskriver EIGRP som en IP-protokol med en multicast-kontroludveksling, og derfor er et nabo-forhold ikke noget, en mellemliggende router kan proxy ved at route pakker mod en destination. Enten når kontroludvekslingen peer’en, eller også dannes naboskabet ikke.

Trin 4: verificér, at transporten leverer kontroludvekslingen

Tjek derefter, om overlayet faktisk bærer kontroltrafikken mellem de tilsigtede endepunkter. Undersøg NHRP-mappingen for peer’en og den ydre rute, der når den, og bekræft derefter, at tunnelinterfacet er oppe og sender trafik. En vellykket underlay-ping beviser, at den ydre vej findes; den beviser ikke, at overlayets kontroludveksling blev leveret.

En transparent Layer 2-tjeneste, en punkt-til-punkt-tunnel og en multipoint-DMVPN-sky leverer multicast forskelligt. Følg den understøttede interface-, NHRP- og multicast-model for den, der faktisk er udrullet, i stedet for at antage, at alle tre opfører sig ens.

Trin 5: redesign grænsen, hvis den ikke kan deltage

Hvis en påkrævet overlay-enhed ikke kan køre protokollen, ændr designet eksplicit. Brug en understøttet protokol eller udvekslingsmodel ved den grænse, eller opsæt en passende end-to-end-tunnel, så naboerne er de endepunkter, der faktisk taler sammen. Antag ikke, at en statisk rute gør en ikke-deltager til en relay for hver kontrolpakke.

Notér hver enheds rolle i diagrammet, og opbevar det sammen med konfigurationen. RFC 7868 definerer protokoludvekslingen, og den definition er reference for, hvorfor nabo-forholdet ikke kan simuleres med transit-videresendelse.

Når naboskabet stadig fejler efter alle fem kontroller, er de resterende mistænkte platformsfunktioner som multicast-håndtering på tunnelinterfacet og politik, der filtrerer protokol 88. Det er konkrete, testbare årsager, og de er mere værd end endnu en runde med at give routeren i midten skylden.