OSPF ar EIGRP per ASA VTI: kurią palaiko jūsų versija

Dauguma OSPF ir EIGRP diskusijų mano, kad tunelis jau gali perduoti protokolą, o ASA atveju būtent ši prielaida yra ta dalis, kurią verta patikrinti pirmiausia. Palyginimas tampa įdomus tik patvirtinus image, VTI tipą ir multicast kelią. Suklydę dėl šios tvarkos, praleisite popietę derindami laikmačius tunelyje, kuris niekada nesudarys kaimynystės. Kiekvieną tokį projektą pradedu nuo leidimo pastabų ir veikiančios konfigūracijos, o ne nuo protokolo preferencijos.

Versija nusprendžia prieš protokolą

Cisco VTI vadovas, skirtas ASA 9.24 yra tinkama dokumentacijos bazė: jame aprašomi statiniai ir dinaminiai VTI ir išvardijamas statinis maršrutizavimas, BGP, OSPF ir EIGRP. Funkcijų istorijoje OSPFv2 ir EIGRP palaikymas VTI yra priskirtas 9.19(1). Viskas, kas senesnė, yra kitas pokalbis.

Taigi pirmieji du klausimai nuobodūs ir lemiami:

Teiginys, kad ASA negali naudoti VTI arba negali perduoti IGP, buvo teisingas kai kuriems senesniems image ir nėra dabartinė palaikymo matrica. Taip pat 9.24 vadovas nėra nurodymas atnaujinti kiekvieną įrenginį. Jis nurodo, ką palaiko ta versija, o jūsų įdiegta versija turi atsakyti už save.

Unicast praėjimas nereiškia, kad IGP susidarys

Tas pats vadovas pažymi, kad unicast praeina pagal nutylėjimą, o multicast turi būti įjungtas OSPFv2 arba EIGRP VTI, su dokumentuotais multicast grupių apribojimais. Tas vienas sakinys paaiškina daugumą nepavykusių kaimynysčių, kurias mačiau šiame projekte. Veikiantis ping per tunelį arba žalias IPsec statusas įrodo tik unicast kelią. Protokolo aptikimui reikia multicast kelio, ir abu konfigūruojami atskirai.

Patikrinkite tunelio sąsajos konfigūraciją dėl to multicast nustatymo, prieš liesdami hello arba hold laikmačius. Jei nustatymo nėra, kaimynystė ne lėta, o neįmanoma.

OSPF ir EIGRP greta tame pačiame tunelyje

Pačiame tunelyje abu protokolai atrodo taip, kaip ir kitur. OSPF reikia atitinkančio tinklo tipo, srities, autentifikavimo ir kaimyno parametrų; EIGRP reikia savo AS numerio ir su juo susijusių sąsajos lygio nustatymų.

Spąstai yra kaimyno teiginių kopijavimas iš kito tunelio modelio. Patarimai dėl statinių kaimynų projekte be VTI egzistavo, kad būtų išvengta multicast, ir jie nepersikelia į VTI, kuris turėtų natūraliai perduoti protokolą. Sukonfigūruokite palaikomą sąsajos elgseną, tada leiskite protokolui pačiam sudaryti kaimynystę.

Tada palyginkite ašyse, kurios jūsų topologijai iš tikrųjų skiriasi: sąveika su kita puse, testuojama konvergencijos elgsena ir jūsų komandos operacinės žinios. Istorinė anekdotas apie tai, kad vienas protokolas greitesnis ar lengvesnis, nėra jūsų tinklo matavimas.

Kaimynai nelygu įdiegtiems maršrutams

Kai kaimynystė pakyla, atskirkite tai, kas generuojama, nuo to, kas priimama. Pažiūrėkite, kokius filialo prefiksus skelbia kiekviena pusė, kurie priimami, kurie parenkami ir kurie iš tikrųjų patenka į maršrutizavimo lentelę. Importo, eksporto ir perskirstymo apimtis turėtų būti apgalvota, o ne bendras visko, ką įrenginys žino, skelbimas.

show ospf neighbor ir show eigrp neighbors pasako, kad sesija gyva. show route pasako, ar filialo prefiksas atėjo, ir tai skirtingi klausimai.

Programos kelias vėl yra trečias klausimas. Kaimynystės ryšys paskirsto pasiekiamumą; jis nesuteikia leidimo per ugniasienę ir neįrodo, kad srauto selektoriai ir filtravimo taisyklės sutampa. Patikrinkite leidžiamą srautą ir jo atsako kelią patvirtintu testu, o ne manydami, kad maršrutas reiškia politiką.

Ką turėtų užfiksuoti baigtas palyginimas

Užrašykite tunelio sąsają, ją palaikančią versiją, patikrintą valdymo mainus ir apibrėžtą maršruto politiką. Pridėkite multicast nustatymą, nes būtent ši detalė tyliai nusprendžia, ar visa kita veikia. Laikykite tą įrašą šalia įdiegtos versijos, kad vėlesnį funkcijos pakeitimą būtų galima peržiūrėti nepradedant iš naujo nuo prielaidos, kuri jau pasibaigė.

Jei kurio nors iš tų keturių trūksta, turite preferenciją, o ne projektą. Pirmiausia ištaisykite trūkstamą faktą; protokolo pasirinkimas yra lengvoji dalis.