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

Nabolaget manglar, og ruteren i midten ser ut som den openberre mistenkte. Han kan vere uskuldig. Å videresenda dei ytre tunnelpakkane og å delta i overlay-rutingprotokollen er to ulike jobbar, og ei eining kan gjere den første utan å gjere den andre. Gå gjennom dei fem kontrollane nedanfor i rekkefølge, og stopp ved den første som feilar.

Steg 1: teikne dei to rollene

Teikne det tiltenkte EIGRP-nabolaget som ei logisk samband mellom to rutarar, og teikne deretter underlay-rutarane som ber tunnelpakkane. Same eining treng ikkje stå på begge listene, og å blande listene er den vanlegaste grunnen til at ein sunn transittruter blir skulda for å øydeleggje nabolaget.

Ein transittruter videresender dei ytre pakkane med si vanlege IP-ruting og -politikk. Han treng ikkje køyre protokollen som blir boren inne i den verna tunnelen, og han treng ingen EIGRP-prosess for å sende pakkane vidare.

Steg 2: kontroller kva eininga i midten terminerer

Viss ruteren i midten terminerer tunnelen og skal danne EIGRP-nabolag med spoke-einingar, endrar svaret seg fullstendig. Den eininga treng den støtta overlay-rutingåferda, og å kalle ho transitt fjernar ikkje nabokravet. Les tunnelkonfigurasjonen før rutingkonfigurasjonen. Det svaret avgjer kvar kontroll som følgjer.

Det første verkelege spørsmålet er altså ikkje kva protokoll som skal justerast. Det er om boksen er ein hub, ein spoke, eit reint underlay-hopp eller ei Layer 2-teneste som ber rammer mellom endepunkt.

Steg 3: verifiser kontrollplanet til naboen

På kvar eining som skal vere nabo, stadfest fire ting: EIGRP-førekomsten og nummeret til det autonome systemet, autentiseringsparametrane, grensesnittet som deltek i prosessen, og nettverkserklæringa som dekkjer grensesnittet. Avvik i éin av dei held nabolaget nede medan grensesnittet er oppe og ping framleis verkar.

RFC 7868 skildrar EIGRP som ein IP-protokoll med ei multicast-kontrollutveksling, og difor er eit nabo-tilhøve ikkje noko ein mellomliggjande ruter kan erstatte ved å rute pakkar mot ein destinasjon. Anten når kontrollutvekslinga fram til peeren, eller så blir ikkje nabolaget danna.

Steg 4: verifiser at transporten leverer kontrollutvekslinga

Sjekk deretter om overlayet faktisk ber kontrolltrafikken mellom dei tiltenkte endepunkta. Undersøk NHRP-mappinga for peeren og den ytre ruta som når han, og stadfest deretter at tunnelgrensesnittet er oppe og slepp trafikk gjennom. Ein vellukka underlay-ping beviser at den ytre vegen finst; han beviser ikkje at kontrollutvekslinga til overlayet vart levert.

Ei gjennomsiktig Layer 2-teneste, ein punkt-til-punkt-tunnel og ei multipoint-DMVPN-sky leverer multicast ulikt. Følg den støtta grensesnitt-, NHRP- og multicast-modellen for den som faktisk er utrulla, i staden for å anta at alle tre oppfører seg likt.

Steg 5: redesign grensa viss ho ikkje kan delta

Viss ei påkravd overlay-eining ikkje kan køyre protokollen, endre designet eksplisitt. Bruk ein støtta protokoll eller utvekslingsmodell ved den grensa, eller set opp ein høveleg ende-til-ende-tunnel slik at naboane er endepunkta som faktisk snakkar saman. Ikkje anta at ei statisk rute gjer ein ikkje-deltakar om til eit relay for kvar kontrollpakke.

Noter rolla til kvar eining i diagrammet og oppbevar henne saman med konfigurasjonen. RFC 7868-definisjonen av protokollutvekslinga er referansen for kvifor nabo-tilhøvet ikkje kan simulerast med transitt-videresending.

Når nabolaget framleis feilar etter alle fem kontrollane, er dei gjenverande mistenkte plattformfunksjonar som multicast-handtering på tunnelgrensesnittet og politikk som filtrerer protokoll 88. Det er konkrete, testbare årsaker, og dei er meir verd enn nok ein runde med å gje ruteren i midten skulda.