OSPF aŭ EIGRP super ASA VTI: kiun subtenas via eldono
OSPFv2 kaj EIGRP trairas ASA VTI nur ekde 9.19(1), kaj nur kun multicast ŝaltita. Komparu la du sur la eldono, kiun vi uzas, poste kontrolu la najbarojn.
Plej multaj diskutoj OSPF kontraŭ EIGRP supozas, ke la tunelo jam povas porti la protokolon, kaj en ASA ĝuste tiu supozo estas la parto, kiun indas kontroli unue. La komparo fariĝas interesa nur post kiam la bildo, la VTI-tipo kaj la multicast-vojo estas konfirmitaj. Eraru pri tiu ordo kaj vi pasigos posttagmezon agordante tempigilojn sur tunelo, kiu neniam formos najbarecon. Mi komencas ĉiun el tiuj projektoj per la eldonaj notoj kaj la kuranta agordo, ne per la protokola prefero.
La eldono decidas antaŭ la protokolo
La VTI-gvidilo de Cisco por ASA 9.24 estas uzebla dokumenta bazo: ĝi priskribas statikajn kaj dinamikajn VTI-ojn kaj listigas statikan enkursigon, BGP, OSPF kaj EIGRP. Ĝia funkcihistorio lokas la subtenon de OSPFv2 kaj EIGRP sur VTI ĉe 9.19(1). Ĉio pli malnova ol tio estas alia konversacio.
Do la du unuaj demandoj estas enuaj kaj decida:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
La aserto, ke ASA ne povas uzi VTI-ojn aŭ ne povas porti IGP, estis vera por kelkaj pli malnovaj bildoj kaj ne estas aktuala subtenmatrico. Same, la gvidilo 9.24 ne estas instrukcio ĝisdatigi ĉiun aparaton. Ĝi diras, kion subtenas tiu eldono, kaj via deplojita eldono devas respondi por si mem.
Trapaso de unicast ne signifas, ke la IGP formiĝos
La sama gvidilo notas, ke unicast trapasas defaŭlte kaj ke multicast devas esti ŝaltita por OSPFv2 aŭ EIGRP sur la VTI, kun dokumentitaj limoj por multicast-grupoj. Tiu unu frazo klarigas la plej multajn malsukcesajn najbarecojn, kiujn mi vidis en ĉi tiu projekto. Funkcianta ping tra la tunelo, aŭ verda IPsec-stato, pruvas nur la unicast-vojon. Protokola malkovro bezonas la multicast-vojon, kaj la du estas agordataj aparte.
Kontrolu la agordon de la tunela interfaco por tiu multicast-agordo antaŭ ol tuŝi la tempigilojn hello aŭ hold. Se la agordo mankas, la najbareco ne estas malrapida, ĝi estas neebla.
OSPF kaj EIGRP flanke apud la sama tunelo
Sur la tunelo mem la du protokoloj aspektas kiel ili aspektas aliloke. OSPF bezonas kunagordan rettipon, areon, aŭtentikigon kaj najbarajn parametrojn; EIGRP bezonas sian AS-numeron kaj la interfacan agordon, kiu iras kun ĝi.
La kaptilo estas kopii najbarajn deklarojn el alia tunela modelo. Konsiloj pri statikaj najbaroj en projekto sen VTI ekzistis por eviti multicast, kaj ĝi ne transdoniĝas al VTI, kiu atendatas natiive porti la protokolon. Agordu la subtenatan interfacan konduton, poste lasu la protokolon formi sian propran najbarecon.
Poste komparu laŭ la aksoj, kiuj vere diferencas por via topologio: interagado kun la alia flanko, konverĝa konduto, kiun vi povas testi, kaj la operacia scio en via teamo. Historia anekdoto pri tio, ke unu protokolo estas pli rapida aŭ pli malpeza, ne estas mezurado de via reto.
Najbaroj ne egalas instalitajn vojojn
Post kiam la najbareco staras, apartigu tion, kio originiĝas, disde tio, kio akceptiĝas. Rigardu, kiujn filiajn prefiksojn ĉiu flanko anoncas, kiuj estas ricevataj, kiuj estas elektataj kaj kiuj vere atingas la enkursigan tabelon. La amplekso de importo, eksporto kaj redistribuo devus esti intenca, ne ĝenerala anonco de ĉio, kion la aparato scias.
show ospf neighbor kaj show eigrp neighbors diras al vi, ke la seanco vivas. show route diras al vi, ĉu la filia prefikso alvenis, kaj tiuj estas malsamaj demandoj.
La aplikada vojo estas denove tria demando. Najbara rilato distribuas atingeblon; ĝi ne donas permeson tra la fajroŝirmilo kaj ne pruvas, ke trafikaj selektiloj kaj filtrado-ruleoj kongruas. Kontrolu la permesitan fluon kaj ĝian respondon-vojon per aprobita testo anstataŭ supozi, ke la vojo implicas la politikon.
Kion la finita komparo devus registri
Notu la tunelan interfacon, la eldonon, kiu subtenas ĝin, la kontrolan interŝanĝon, kiun vi kontrolis, kaj la vojpolitikon, kiun vi limigis. Aldonu la multicast-agordon, ĉar ĝi estas la detalo, kiu silente decidas, ĉu io ajn el la resto funkcias. Konservu tiun registron apud la deplojita eldono, por ke posta funkcia ŝanĝo povu esti reviziita sen rekomenci de supozo, kiu intertempe eksvalidiĝis.
Se mankas iu el tiuj kvar, vi havas preferon anstataŭ planon. Riparu unue la mankan fakton; la protokola elekto estas la facila parto.