EIGRP soused, nebo DMVPN tranzit? Nejdřív zkontrolujte roli

Sousedství chybí a router uprostřed vypadá jako zjevný podezřelý. Může být nevinný. Přeposílání vnějších paketů tunelu a účast v overlay směrovacím protokolu jsou dvě různé úlohy a zařízení může dělat první, aniž by dělalo druhou. Projděte pět kontrol níže popořadě a zastavte se u první, která selže.

Krok 1: nakreslete dvě role

Nakreslete zamýšlené sousedství EIGRP jako logické spojení mezi dvěma routery a potom nakreslete underlay routery, které přenášejí jeho pakety tunelu. Stejné zařízení nemusí být v obou seznamech a záměna seznamů je nejčastějším důvodem, proč je zdravý tranzitní router obviňován z rozbití sousedství.

Tranzitní router přeposílá vnější pakety svým běžným IP směrováním a politikou. Nemusí spouštět protokol nesený uvnitř chráněného tunelu a nepotřebuje proces EIGRP, aby tyto pakety předal dál.

Krok 2: zkontrolujte, co prostřední zařízení ukončuje

Pokud prostřední router ukončuje tunel a má tvořit sousedství EIGRP se spoke zařízeními, odpověď se zcela mění. Takové zařízení potřebuje podporované overlay směrovací chování a označení tranzit požadavek na souseda neruší. Přečtěte konfiguraci tunelu dřív než konfiguraci směrování. Tato odpověď určuje každou následující kontrolu.

První skutečná otázka tedy není, který protokol ladit. Je to, zda je zařízení hub, spoke, čistý underlay hop, nebo služba Layer 2, která přenáší rámce mezi koncovými body.

Krok 3: ověřte řídicí rovinu souseda

Na každém zařízení, které má být sousedem, potvrďte čtyři věci: instanci EIGRP a číslo autonomního systému, parametry autentizace, rozhraní účastnící se procesu a síťový příkaz, který toto rozhraní pokrývá. Neshoda v kterékoli z nich drží sousedství dole, zatímco rozhraní zůstává nahoře a ping dál funguje.

RFC 7868 popisuje EIGRP jako IP protokol s multicastovou výměnou řízení, a proto sousedský vztah není něco, co by mezilehlý router mohl zastoupit směrováním paketů k cíli. Buď výměna řízení dorazí k protějšku, nebo se sousedství nevytvoří.

Krok 4: ověřte, že transport doručuje výměnu řízení

Dále ověřte, že overlay skutečně přenáší řídicí provoz mezi zamýšlenými koncovými body. Prohlédněte mapování NHRP pro protějšek a vnější trasu, která k němu vede, a potom potvrďte, že rozhraní tunelu je nahoře a propouští provoz. Úspěšný underlay ping dokazuje, že vnější cesta existuje; nedokazuje, že byla doručena výměna řízení overlay.

Transparentní služba Layer 2, tunel bod-bod a multipointový cloud DMVPN doručují multicast odlišně. Postupujte podle podporovaného modelu rozhraní, NHRP a multicastu pro to, co je skutečně nasazeno, místo abyste předpokládali, že všechny tři se chovají stejně.

Krok 5: přeprojektujte hranici, pokud se nemůže účastnit

Pokud požadované overlay zařízení nedokáže spustit protokol, změňte návrh výslovně. Použijte na této hranici podporovaný protokol nebo model výměny, nebo zajistěte vhodný tunel end-to-end, aby sousedy byly koncové body, které spolu skutečně komunikují. Nepředpokládejte, že statická trasa promění neúčastníka v přeposílač každého řídicího paketu.

Zapište roli každého zařízení do diagramu a uchovávejte ji s konfigurací. RFC 7868 definuje výměnu protokolu a tato definice je referencí pro to, proč nelze sousedský vztah simulovat tranzitním přeposíláním.

Když sousedství selže i po všech pěti kontrolách, zbývajícími podezřelými jsou funkce platformy, jako je zpracování multicastu na rozhraní tunelu a politika, která filtruje protokol 88. To jsou konkrétní, testovatelné příčiny a mají větší cenu než další kolo obviňování prostředního routeru.