OSPF sau EIGRP prin VTI pe ASA: care dintre ele e susținut de versiunea ta

Majoritatea dezbaterilor OSPF versus EIGRP presupun că tunelul poate deja transporta protocolul, iar pe un ASA chiar această presupunere este partea care merită verificată prima. Comparația devine interesantă abia după ce imaginea, tipul de VTI și calea multicast sunt confirmate. Greșești această ordine și petreci o după-amiază reglând temporizatoare pe un tunel care nu va forma niciodată o adiacență. Încep fiecare dintre aceste proiecte cu notele versiunii și configurația în execuție, nu cu preferința de protocol.

Versiunea decide înaintea protocolului

Ghidul VTI al Cisco pentru ASA 9.24 este o bază documentară utilizabilă: descrie VTI statice și dinamice și listează rutare statică, BGP, OSPF și EIGRP. Istoricul funcțiilor plasează suportul pentru OSPFv2 și EIGRP pe VTI la 9.19(1). Orice este mai vechi este altă discuție.

Așadar primele două întrebări sunt plictisitoare și decisive:

Afirmația că un ASA nu poate folosi VTI sau nu poate transporta un IGP era adevărată pentru unele imagini mai vechi și nu este o matrice de suport actuală. La fel, ghidul 9.24 nu este o instrucțiune de a actualiza fiecare echipament. El spune ce suportă acea versiune, iar versiunea ta implementată trebuie să răspundă pentru sine.

Faptul că unicast trece nu înseamnă că IGP-ul se va forma

Același ghid notează că unicast trece implicit și că multicast trebuie activat pentru OSPFv2 sau EIGRP pe VTI, cu limite documentate la grupurile multicast. Acea singură frază explică majoritatea adiacențelor eșuate pe care le-am văzut la acest proiect. Un ping care funcționează prin tunel sau un status IPsec verde dovedește doar calea unicast. Descoperirea protocolului are nevoie de calea multicast, iar cele două se configurează separat.

Verifică în configurația interfeței tunelului acea setare de multicast înainte să atingi temporizatoarele hello sau hold. Dacă setarea lipsește, adiacența nu este lentă, este imposibilă.

OSPF și EIGRP una lângă alta pe același tunel

Pe tunelul propriu-zis cele două protocoale arată ca oriunde altundeva. OSPF are nevoie de un tip de rețea potrivit, zonă, autentificare și parametri de vecin; EIGRP are nevoie de numărul său AS și de setările la nivel de interfață care îl însoțesc.

Capcana este copierea instrucțiunilor de vecin dintr-un alt model de tunel. Sfaturile despre vecinii statici într-un proiect fără VTI existau pentru a evita multicast, iar ele nu se transferă la un VTI care ar trebui să transporte protocolul nativ. Configurează comportamentul de interfață acceptat, apoi lasă protocolul să își formeze propria adiacență.

Apoi compară pe axele care chiar diferă pentru topologia ta: interoperabilitatea cu cealaltă parte, comportamentul de convergență pe care îl poți testa și cunoștințele operaționale din echipa ta. O anecdotă istorică despre un protocol mai rapid sau mai ușor nu este o măsurare a rețelei tale.

Vecinii nu sunt egali cu rutele instalate

După ce adiacența este sus, separă ce este originat de ce este acceptat. Uită-te la ce prefixe de sucursală anunță fiecare parte, care sunt primite, care sunt selectate și care ajung efectiv în tabela de rutare. Domeniul de import, export și redistribuire ar trebui să fie deliberat, nu un anunț general pentru tot ce știe dispozitivul.

show ospf neighbor și show eigrp neighbors îți spun că sesiunea este vie. show route îți spune dacă prefixul sucursalei a ajuns, și acestea sunt întrebări diferite.

Calea aplicației este din nou o a treia întrebare. O relație de vecinătate distribuie accesibilitate; ea nu acordă permisiune prin firewall și nu dovedește că selectoarele de trafic și regulile de filtrare sunt de acord. Verifică fluxul permis și calea lui de răspuns cu un test aprobat în loc să presupui că ruta implică politica.

Ce ar trebui să consemneze comparația finalizată

Notează interfața tunelului, versiunea care o suportă, schimbul de control pe care l-ai verificat și politica de rute pe care ai delimitat-o. Adaugă setarea de multicast, pentru că este detaliul care decide în tăcere dacă restul funcționează. Păstrează acea consemnare lângă versiunea implementată, ca o modificare ulterioară de funcție să poată fi analizată fără a reporni de la o presupunere care între timp a expirat.

Dacă lipsește oricare dintre aceste patru, ai o preferință și nu un proiect. Corectează mai întâi faptul lipsă; alegerea protocolului este partea ușoară.