A szomszédság hiányzik, és a középső router tűnik a kézenfekvő gyanúsítottnak. Lehet ártatlan. A külső alagútcsomagok továbbítása és az overlay routingprotokollban való részvétel két külön feladat, és egy eszköz az elsőt a második nélkül is elvégezheti. Végezze el az alábbi öt ellenőrzést sorrendben, és álljon meg az elsőnél, amelyik megbukik.

1. lépés: rajzolja fel a két szerepet

Rajzolja fel a tervezett EIGRP-szomszédságot két router közötti logikai kapcsolatként, majd rajzolja fel azokat az underlay routereket, amelyek az alagútcsomagjait szállítják. Ugyanannak az eszköznek nem kell mindkét listán szerepelnie, és a listák összekeverése a leggyakoribb oka annak, hogy egy egészséges tranzitroutert a szomszédság megtörésével vádolnak.

A tranzitrouter a szokásos IP-routingjával és szabályzatával továbbítja a külső csomagokat. Nem kell futtatnia a védett alagúton belül szállított protokollt, és nincs szüksége EIGRP-folyamatra ahhoz, hogy ezeket a csomagokat továbbadja.

2. lépés: ellenőrizze, mit terminál a középső eszköz

Ha a középső router terminálja az alagutat, és EIGRP-szomszédságokat kell kialakítania spoke-eszközökkel, a válasz teljesen megváltozik. Ennek az eszköznek a támogatott overlay-routingviselkedésre van szüksége, és a tranzitnak nevezés nem szünteti meg a szomszéd követelményét. A routingkonfiguráció előtt olvassa el az alagút konfigurációját. Ez a válasz határozza meg az összes következő ellenőrzést.

Az első igazi kérdés tehát nem az, melyik protokollt kell hangolni. Hanem az, hogy a doboz hub, spoke, tiszta underlay-hop vagy olyan Layer 2 szolgáltatás, amely kereteket szállít a végpontok között.

3. lépés: ellenőrizze a szomszéd vezérsíkját

Minden eszközön, amelynek szomszédnak kell lennie, négy dolgot erősítsen meg: az EIGRP-példányt és az autonóm rendszer számát, a hitelesítési paramétereket, a folyamatban részt vevő interfészt és az interfészt lefedő hálózati utasítást. Ha ezek bármelyike eltér, a szomszédság lent marad, miközben az interfész fent van, és a ping tovább működik.

Az RFC 7868 az EIGRP-t multicast vezérlőcserével rendelkező IP-protokollként írja le, ezért a szomszédviszony nem olyasmi, amit egy köztes router helyettesíthetne a csomagok cél felé irányításával. Vagy eljut a vezérlőcsere a partnerhez, vagy nem jön létre a szomszédság.

4. lépés: ellenőrizze, hogy a szállítás eljuttatja-e a vezérlőcserét

Ezután ellenőrizze, hogy az overlay tényleg szállítja-e a vezérlőforgalmat a tervezett végpontok között. Vizsgálja meg a partner NHRP-leképezését és a hozzá vezető külső útvonalat, majd erősítse meg, hogy az alagút interfésze fent van és átenged forgalmat. A sikeres underlay ping bizonyítja, hogy a külső útvonal létezik; azt nem bizonyítja, hogy az overlay vezérlőcseréje megérkezett.

Az átlátszó Layer 2 szolgáltatás, a pont-pont alagút és a többpontos DMVPN felhő másképp továbbítja a multicastot. A ténylegesen telepített megoldás támogatott interfész-, NHRP- és multicastmodelljét kövesse ahelyett, hogy feltételezné, mindhárom ugyanúgy viselkedik.

5. lépés: tervezze újra a határt, ha nem tud részt venni

Ha egy szükséges overlay-eszköz nem tudja futtatni a protokollt, változtassa meg a tervet egyértelműen. Használjon támogatott protokollt vagy cseremodellt ezen a határon, vagy alakítson ki megfelelő végponttól végpontig alagutat, hogy a szomszédok azok a végpontok legyenek, amelyek tényleg beszélnek egymással. Ne feltételezze, hogy egy statikus útvonal minden vezérlőcsomag továbbítójává teszi a nem résztvevőt.

Jegyezze fel az egyes eszközök szerepét a diagramon, és őrizze meg a konfiguráció mellett. RFC 7868 meghatározza a protokollcserét, és ez a meghatározás a hivatkozás arra, miért nem szimulálható a szomszédviszony tranzittovábbítással.

Ha a szomszédság mind az öt ellenőrzés után sem jön létre, a fennmaradó gyanúsítottak platformfunkciók, például a multicast kezelése az alagút interfészén és a 88-as protokollt szűrő szabályzat. Ezek konkrét, tesztelhető okok, és többet érnek, mint a középső router hibáztatásának újabb fordulója.

Kapcsolódó cikkek