OSPF alebo EIGRP cez VTI na ASA: ktorú podporuje vaša verzia

Väčšina diskusií OSPF verzus EIGRP predpokladá, že tunel už dokáže prenášať protokol, a na ASA je práve tento predpoklad tou časťou, ktorú treba overiť najskôr. Porovnanie začne byť zaujímavé až po potvrdení image, typu VTI a multicastovej cesty. Pomýlite poradie a strávite popoludnie ladením časovačov na tuneli, ktorý nikdy nevytvorí susedstvo. Každý z týchto návrhov začínam poznámkami k verzii a bežiacou konfiguráciou, nie preferenciou protokolu.

Verzia rozhoduje pred protokolom

Sprievodca Cisco k VTI na ASA 9.24 je použiteľná dokumentačná základňa: opisuje statické a dynamické VTI a uvádza statické smerovanie, BGP, OSPF a EIGRP. Jeho história funkcií zaraďuje podporu OSPFv2 a EIGRP na VTI k verzii 9.19(1). Čokoľvek staršie je iná kapitola.

Takže prvé dve otázky sú nudné a rozhodujúce:

Tvrdenie, že ASA nevie používať VTI alebo neunesie IGP, platilo pre niektoré staršie image a nie je aktuálnou maticou podpory. Rovnako sprievodca k 9.24 nie je pokynom upgradovať každé zariadenie. Hovorí, čo daná verzia podporuje, a vaša nasadená verzia musí odpovedať sama za seba.

Prechádzajúci unicast neznamená, že sa IGP vytvorí

Ten istý sprievodca uvádza, že unicast prechádza predvolene a že multicast treba pre OSPFv2 alebo EIGRP na VTI zapnúť, s dokumentovanými limitmi multicastových skupín. Tá jediná veta vysvetľuje väčšinu neúspešných susedstiev, ktoré som pri tomto návrhu videl. Fungujúci ping tunelom alebo zelený stav IPsec dokazuje len unicastovú cestu. Objavovanie protokolu potrebuje multicastovú cestu a obe sa konfigurujú oddelene.

Skontrolujte konfiguráciu tunelového rozhrania, či toto multicastové nastavenie obsahuje, skôr než siahnete na časovače hello alebo hold. Ak nastavenie chýba, susedstvo nie je pomalé, je nemožné.

OSPF a EIGRP vedľa seba na tom istom tuneli

Na tuneli samotnom vyzerajú oba protokoly ako inde. OSPF potrebuje zodpovedajúci typ siete, oblasť, autentifikáciu a parametre susedov; EIGRP potrebuje svoje číslo AS a nastavenia na úrovni rozhrania, ktoré k tomu patria.

Pascou je kopírovanie príkazov pre susedov z iného modelu tunela. Rady o statických susedoch v návrhu bez VTI existovali preto, aby sa vyhli multicastu, a neprenášajú sa na VTI, od ktorého sa očakáva natívny prenos protokolu. Nakonfigurujte podporované správanie rozhrania a nechajte protokol, aby si susedstvo vytvoril sám.

Potom porovnávajte na osiach, ktoré sa pre vašu topológiu skutočne líšia: interoperabilita s druhou stranou, správanie konvergencie, ktoré môžete otestovať, a prevádzkové znalosti vo vašom tíme. Historická anekdota o tom, že jeden protokol je rýchlejší alebo ľahší, nie je meraním vašej siete.

Susedia sa nerovnajú nainštalovaným trasám

Keď susedstvo stojí, oddeľte, čo sa inzeruje, od toho, čo sa prijíma. Pozrite sa, ktoré prefixy pobočiek každá strana inzeruje, ktoré sa prijímajú, ktoré sa vyberajú a ktoré sa skutočne dostanú do smerovacej tabuľky. Rozsah importu, exportu a redistribúcie má byť zámerný, nie plošná reklama na všetko, čo zariadenie vie.

show ospf neighbor a show eigrp neighbors vám povedia, že relácia žije. show route vám povie, či prefix pobočky dorazil, a to sú rôzne otázky.

Cesta aplikácie je znova tretia otázka. Susedský vzťah distribuuje dostupnosť; neudeľuje povolenie cez firewall a nedokazuje, že selektory prevádzky a pravidlá filtrovania súhlasia. Overte povolený tok a jeho spätnú cestu schváleným testom, namiesto toho aby ste predpokladali, že trasa znamená politiku.

Čo má hotové porovnanie zaznamenať

Zapíšte tunelové rozhranie, verziu, ktorá ho podporuje, riadiacu výmenu, ktorú ste overili, a pravidlá smerovania, ktoré ste ohraničili. Pridajte multicastové nastavenie, pretože práve tento detail potichu rozhoduje, či zvyšok funguje. Uchovajte tento záznam vedľa nasadenej verzie, aby sa neskoršia zmena funkcie dala posúdiť bez štartu z predpokladu, ktorý medzitým vypršal.

Ak chýba čokoľvek z tých štyroch, máte preferenciu, nie návrh. Najprv opravte chýbajúci fakt; voľba protokolu je tá ľahká časť.