OSPF vagy EIGRP ASA VTI felett: melyiket támogatja a verziója

A legtöbb OSPF kontra EIGRP vita feltételezi, hogy az alagút már képes hordozni a protokollt, és egy ASA-n éppen ez a feltételezés az a rész, amit érdemes először ellenőrizni. Az összehasonlítás csak akkor válik érdekessé, ha a kép, a VTI-típus és a multicast útvonal már igazolt. Ha ezt a sorrendet elvéti, egy délutánt tölt az időzítők hangolásával egy olyan alagúton, amely soha nem fog szomszédságot kialakítani. Minden ilyen tervet a kiadási megjegyzésekkel és a futó konfigurációval kezdek, nem a protokoll preferenciával.

A verzió dönt, még a protokoll előtt

A Cisco VTI útmutatója az ASA 9.24-hez használható dokumentációs alap: leírja a statikus és dinamikus VTI-ket, és felsorolja a statikus útválasztást, a BGP-t, az OSPF-et és az EIGRP-t. A funkciótörténete az OSPFv2 és az EIGRP VTI-támogatását a 9.19(1) verzióhoz teszi. Minden, ami ennél régebbi, más beszélgetés.

Tehát az első két kérdés unalmas és döntő:

Az az állítás, hogy egy ASA nem tud VTI-t használni, vagy nem tud IGP-t hordozni, bizonyos régebbi képeknél igaz volt, és nem jelenlegi támogatási mátrix. Ugyanígy a 9.24 útmutató nem utasítás minden eszköz frissítésére. Megmondja, mit támogat az a verzió, és a telepített verziójának magáért kell válaszolnia.

Az unicast átjutása nem jelenti azt, hogy az IGP létrejön

Ugyanez az útmutató megjegyzi, hogy az unicast alapértelmezés szerint átjut, és a multicastot engedélyezni kell az OSPFv2 vagy az EIGRP számára a VTI-n, dokumentált multicast-csoportkorlátokkal. Ez az egyetlen mondat magyarázza a legtöbb sikertelen szomszédságot, amit ebben a tervben láttam. Egy működő ping az alagúton, vagy egy zöld IPsec-állapot, csak az unicast útvonalat bizonyítja. A protokoll-felderítéshez a multicast útvonal kell, és a kettőt külön konfigurálják.

Ellenőrizze az alagút interfész konfigurációjában ezt a multicast beállítást, mielőtt a hello vagy hold időzítőkhöz nyúl. Ha a beállítás hiányzik, a szomszédság nem lassú, hanem lehetetlen.

OSPF és EIGRP egymás mellett ugyanazon az alagúton

Magán az alagúton a két protokoll úgy néz ki, mint bárhol máshol. Az OSPF-nek egyező hálózattípusra, területre, hitelesítésre és szomszédparaméterekre van szüksége; az EIGRP-nek a saját AS-számára és a hozzá tartozó interfészszintű beállításokra.

A csapda a szomszédutasítások másolása egy másik alagútmodellből. A statikus szomszédokról szóló tanács a VTI nélküli tervben a multicast elkerülését szolgálta, és nem vihető át olyan VTI-re, amelynél elvárás, hogy a protokollt natívan hordozza. Konfigurálja a támogatott interfészviselkedést, majd hagyja, hogy a protokoll kialakítsa a saját szomszédságát.

Ezután azokon a tengelyeken hasonlítson össze, amelyek a topológiájában valóban különböznek: a másik oldallal való együttműködés, a tesztelhető konvergenciaviselkedés és a csapat üzemeltetési tudása. Egy történelmi anekdota arról, hogy az egyik protokoll gyorsabb vagy könnyebb, nem a hálózat mérése.

A szomszédok nem egyenlők a telepített útvonalakkal

Amikor a szomszédság feláll, válassza szét azt, ami keletkezik, attól, ami elfogadásra kerül. Nézze meg, mely ág-prefixeket hirdeti meg mindkét oldal, melyek érkeznek meg, melyek kerülnek kiválasztásra, és melyek érik el ténylegesen az útválasztási táblát. Az import, az export és az újraelosztás hatókörének szándékosnak kell lennie, nem pedig az eszköz által ismert minden dolog átfogó hirdetésének.

show ospf neighbor és show eigrp neighbors megmondják, hogy a munkamenet él. show route megmondja, hogy megérkezett-e az ág-prefix, és ezek különböző kérdések.

Az alkalmazásútvonal ismét harmadik kérdés. A szomszédsági kapcsolat elérhetőséget oszt el; nem ad engedélyt a tűzfalon keresztül, és nem bizonyítja, hogy a forgalomszelektorok és a szűrési szabályok egyetértenek. Ellenőrizze az engedélyezett folyamot és annak válaszútvonalát jóváhagyott teszttel, ahelyett hogy feltételezné, hogy az útvonal magában foglalja a szabályzatot.

Mit rögzítsen a kész összehasonlítás

Írja fel az alagút interfészt, az azt támogató verziót, az ellenőrzött vezérlécserét és a behatárolt útvonal-szabályzatot. Adja hozzá a multicast beállítást, mert ez az a részlet, amely csendben eldönti, hogy a többi működik-e. Tartsa ezt a feljegyzést a telepített verzió mellett, hogy egy későbbi funkcióváltozás áttekinthető legyen anélkül, hogy egy közben lejárt feltételezésből indulna újra.

Ha a négy közül bármelyik hiányzik, akkor preferenciája van, nem terve. Először a hiányzó tényt javítsa; a protokoll választása a könnyű rész.