EIGRP sused alebo DMVPN tranzit? Najprv skontrolujte rolu

Susedstvo chýba a router v strede vyzerá ako zjavný podozrivý. Môže byť nevinný. Preposielanie vonkajších paketov tunela a účasť v overlay smerovacom protokole sú dve rôzne úlohy a zariadenie môže robiť prvú bez druhej. Prejdite päť kontrol nižšie poporiadku a zastavte sa pri prvej, ktorá zlyhá.

Krok 1: nakreslite dve roly

Nakreslite zamýšľané susedstvo EIGRP ako logické spojenie medzi dvoma routermi, potom nakreslite underlay routery, ktoré prenášajú jeho pakety tunela. To isté zariadenie nemusí byť v oboch zoznamoch a zámena zoznamov je najčastejším dôvodom, prečo je zdravý tranzitný router obviňovaný z porušenia susedstva.

Tranzitný router preposiela vonkajšie pakety svojím bežným IP smerovaním a politikou. Nemusí spúšťať protokol prenášaný vnútri chráneného tunela a nepotrebuje proces EIGRP na to, aby tieto pakety posielal ďalej.

Krok 2: skontrolujte, čo ukončuje prostredné zariadenie

Ak prostredný router ukončuje tunel a má vytvárať susedstvá EIGRP so spoke, odpoveď sa úplne mení. Také zariadenie potrebuje podporované overlay smerovacie správanie a označenie tranzit neodstraňuje požiadavku na suseda. Prečítajte konfiguráciu tunela pred konfiguráciou smerovania. Táto odpoveď určuje každú nasledujúcu kontrolu.

Prvá skutočná otázka teda nie je, ktorý protokol ladiť. Je to, či je zariadenie hub, spoke, čistý underlay hop alebo služba Layer 2, ktorá prenáša rámce medzi koncovými bodmi.

Krok 3: overte riadiacu rovinu suseda

Na každom zariadení, ktoré má byť susedom, potvrďte štyri veci: inštanciu EIGRP a číslo autonómneho systému, parametre autentifikácie, rozhranie zúčastňujúce sa procesu a sieťový príkaz, ktorý toto rozhranie pokrýva. Nezhoda v ktorejkoľvek z nich drží susedstvo dole, zatiaľ čo rozhranie zostáva hore a ping ďalej funguje.

RFC 7868 opisuje EIGRP ako IP protokol s multicastovou výmenou riadenia, a preto susedský vzťah nie je niečo, čo by medziľahlý router mohol zastúpiť smerovaním paketov k cieľu. Buď výmena riadenia dorazí k partnerovi, alebo sa susedstvo nevytvorí.

Krok 4: overte, že transport doručuje výmenu riadenia

Ďalej overte, či overlay skutočne prenáša riadiacu prevádzku medzi zamýšľanými koncovými bodmi. Prezrite mapovanie NHRP pre partnera a vonkajšiu trasu, ktorá k nemu vedie, a potom potvrďte, že rozhranie tunela je hore a prepúšťa prevádzku. Úspešný underlay ping dokazuje, že vonkajšia cesta existuje; nedokazuje, že bola doručená výmena riadenia overlay.

Transparentná služba Layer 2, tunel bod-bod a multipointový cloud DMVPN doručujú multicast odlišne. Postupujte podľa podporovaného modelu rozhrania, NHRP a multicastu pre to, čo je skutočne nasadené, namiesto predpokladu, že všetky tri sa správajú rovnako.

Krok 5: prepracujte hranicu, ak sa nemôže zúčastniť

Ak požadované overlay zariadenie nedokáže spustiť protokol, zmeňte návrh výslovne. Použite na tejto hranici podporovaný protokol alebo model výmeny, alebo zabezpečte vhodný tunel od konca ku koncu, aby susedmi boli koncové body, ktoré spolu skutočne komunikujú. Nepredpokladajte, že statická trasa premení neúčastníka na preposielač každého riadiaceho paketu.

Zapíšte rolu každého zariadenia do diagramu a uchovávajte ju s konfiguráciou. RFC 7868 definuje výmenu protokolu a táto definícia je referenciou pre to, prečo nemožno susedský vzťah simulovať tranzitným preposielaním.

Keď susedstvo zlyhá aj po všetkých piatich kontrolách, zostávajúcimi podozrivými sú funkcie platformy, ako je spracovanie multicastu na rozhraní tunela a politika, ktorá filtruje protokol 88. Sú to konkrétne, testovateľné príčiny a majú väčšiu cenu než ďalšie kolo obviňovania prostredného routera.