OSPF nebo EIGRP přes VTI na ASA: kterou verze podporuje

Většina argumentů OSPF versus EIGRP předpokládá, že tunel už protokol unese, a na ASA je právě tento předpoklad tou částí, kterou je třeba ověřit jako první. Srovnání začne být zajímavé až poté, co potvrdíte image, typ VTI a multicastovou cestu. Popleťte pořadí a strávíte odpoledne laděním časovačů na tunelu, který nikdy nevytvoří sousedství. Každý z těchto návrhů začínám poznámkami k verzi a běžící konfigurací, ne preferencí protokolu.

Verze rozhoduje dřív než protokol

Průvodce Cisco k VTI na ASA 9.24 je použitelná dokumentační základna: popisuje statické i dynamické VTI a uvádí statické směrování, BGP, OSPF a EIGRP. Jeho historie funkcí řadí podporu OSPFv2 a EIGRP na VTI k verzi 9.19(1). Cokoli staršího je jiná kapitola.

Takže první dvě otázky jsou nudné a rozhodující:

Tvrzení, že ASA neumí VTI nebo neunese IGP, platilo pro některé starší image a není aktuální maticí podpory. Stejně tak průvodce k 9.24 není pokynem upgradovat každý přístroj. Říká, co daná verze podporuje, a vaše nasazená verze musí odpovědět sama za sebe.

Procházející unicast neznamená, že se IGP vytvoří

Stejný průvodce uvádí, že unicast prochází ve výchozím stavu a že multicast musí být pro OSPFv2 nebo EIGRP na VTI povolen, s dokumentovanými limity multicastových skupin. Tahle jediná věta vysvětluje většinu neúspěšných sousedství, která jsem u tohoto návrhu viděl. Fungující ping tunelem nebo zelený stav IPsec dokazuje jen unicastovou cestu. Objevování protokolu potřebuje multicastovou cestu a obojí se konfiguruje odděleně.

Zkontrolujte konfiguraci tunelového rozhraní, zda toto multicastové nastavení obsahuje, dřív než sáhnete na časovače hello nebo hold. Pokud nastavení chybí, sousedství není pomalé, je nemožné.

OSPF a EIGRP vedle sebe na stejném tunelu

Na tunelu samotném vypadají oba protokoly jako jinde. OSPF potřebuje odpovídající typ sítě, oblast, autentizaci a parametry sousedů; EIGRP potřebuje své číslo AS a nastavení na úrovni rozhraní, která k němu patří.

Pastí je kopírování příkazů pro sousedy z jiného modelu tunelu. Rady o statických sousedech v návrhu bez VTI existovaly proto, aby se vyhnuly multicastu, a nepřenášejí se na VTI, od které se očekává nativní přenos protokolu. Nakonfigurujte podporované chování rozhraní a nechte protokol, ať si sousedství vytvoří sám.

Potom porovnávejte na osách, které se pro vaši topologii skutečně liší: interoperabilita s druhou stranou, chování konvergence, které můžete otestovat, a provozní znalosti ve vašem týmu. Historická anekdota o tom, že jeden protokol je rychlejší nebo lehčí, není měřením vaší sítě.

Sousedé se nerovnají nainstalovaným trasám

Když sousedství stojí, oddělte, co se inzeruje, od toho, co se přijímá. Podívejte se, které prefixy poboček každá strana inzeruje, které se přijímají, které se vybírají a které se skutečně dostanou do směrovací tabulky. Rozsah importu, exportu a redistribuce má být záměrný, ne plošná reklama na všechno, co zařízení ví.

show ospf neighbor a show eigrp neighbors vám řekne, že relace žije. show route vám řekne, zda prefix pobočky dorazil, a to jsou různé otázky.

Cesta aplikace je znovu třetí otázka. Sousedský vztah distribuuje dostupnost; neuděluje povolení přes firewall a nedokazuje, že selektory provozu a filtrační pravidla souhlasí. Ověřte povolený tok a jeho zpětnou cestu schváleným testem, místo abyste předpokládali, že trasa znamená politiku.

Co má hotové srovnání zaznamenat

Zapište tunelové rozhraní, verzi, která ho podporuje, řídicí výměnu, kterou jste ověřili, a pravidla směrování, která jste ohraničili. Přidejte multicastové nastavení, protože právě tento detail tiše rozhoduje, zda zbytek funguje. Uchovejte tento záznam vedle nasazené verze, aby šlo pozdější změnu funkce posoudit bez startu z předpokladu, který mezitím vypršel.

Chybí-li cokoli ze těch čtyř, máte preferenci, ne návrh. Opravte nejdřív chybějící fakt; volba protokolu je ta snadná část.