EIGRP-szomszéd vagy DMVPN-tranzit? Előbb ellenőrizze a szerepet
A középső router továbbíthatja a külső alagútcsomagokat EIGRP futtatása nélkül. Döntse el, hogy az eszköz tranzit vagy szomszéd, mielőtt a szomszédságot hibakeresné.
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.