OSPF eller EIGRP over ein ASA VTI: kva versjonen din støttar
OSPFv2 og EIGRP går over ein ASA VTI først frå 9.19(1), og berre med multicast slått på. Samanlikn dei to på versjonen du køyrer, og kontroller deretter naboane.
Dei fleste OSPF-mot-EIGRP-diskusjonane føreset at tunnelen allereie kan bera protokollen, og på ein ASA er nettopp den føresetnaden den delen som er verd å kontrollera først. Samanlikninga blir først interessant etter at image, VTI-type og multicast-sti er stadfesta. Tek du feil av den rekkjefølgja, brukar du ein ettermiddag på å justera timar på ein tunnel som aldri vil danna eit naboskap. Eg startar kvart av desse designa med utgivingsnotata og den køyrande konfigurasjonen, ikkje med protokollpreferansen.
Versjonen avgjer før protokollen
Cisco si VTI-rettleiing for ASA 9.24 er eit brukbart dokumentasjonsgrunnlag: ho skildrar statiske og dynamiske VTI-ar og listar statisk ruting, BGP, OSPF og EIGRP. Funksjonshistoria plasserer OSPFv2- og EIGRP-støtte på VTI ved 9.19(1). Alt eldre enn det er ein annan samtale.
Så dei to første spørsmåla er keisamelege og avgjerande:
| 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 |
Påstanden om at ein ASA ikkje kan bruka VTI-ar eller ikkje kan bera ein IGP, var sann for nokre eldre images og er ikkje ein gjeldande støttematrise. På same måte er ikkje 9.24-rettleiinga ein instruks om å oppgradera kvar eining. Ho fortel kva den versjonen støttar, og den utrulla versjonen din må svara for seg sjølv.
At unicast slepp gjennom betyr ikkje at IGP-en blir danna
Den same rettleiinga nemner at unicast passerer som standard, og at multicast må slåast på for OSPFv2 eller EIGRP på VTI-en, med dokumenterte grenser for multicast-grupper. Den eine setninga forklarar dei fleste mislukka naboskapane eg har sett på dette designet. Ein ping som verkar gjennom tunnelen, eller ein grøn IPsec-status, beviser berre unicast-stien. Protokolloppdaging treng multicast-stien, og dei to blir konfigurerte kvar for seg.
Kontroller tunnelgrensesnitt-konfigurasjonen for den multicast-innstillinga før du rører hello- eller hold-timar. Viss innstillinga manglar, er naboskapet ikkje tregt, det er umogeleg.
OSPF og EIGRP side om side på same tunnel
På sjølve tunnelen ser dei to protokollane ut som dei gjer elles. OSPF treng ein samsvarande nettverkstype, område, autentisering og nabo-parameterar; EIGRP treng AS-nummeret sitt og innstillingane på grensesnittnivå som høyrer til.
Fella er å kopiera nabooppsett frå ein annan tunnelmodell. Råd om statiske naboar i eit design utan VTI fanst for å unngå multicast, og dei blir ikkje overførte til ein VTI som er venta å bera protokollen naturleg. Konfigurer den støtta grensesnittåtferda, og la deretter protokollen danna sitt eige naboskap.
Samanlikn deretter på aksane som faktisk er ulike for topologien din: interoperabilitet med den andre sida, konvergensåtferd du kan testa, og driftskunnskapen i teamet ditt. Ei historisk anekdote om at den eine protokollen er raskare eller lettare, er ikkje ei måling av nettverket ditt.
Naboar er ikkje det same som installerte ruter
Når naboskapet er oppe, skil det som blir originert frå det som blir akseptert. Sjå på kva grenprefiks kvar side annonserer, kva som blir mottekne, kva som blir valde, og kva som faktisk når rutetabellen. Omfanget av import, eksport og redistribusjon bør vera medvite i staden for ein samla annonsering av alt eininga veit.
show ospf neighbor og show eigrp neighbors fortel deg at sesjonen er levande. show route fortel deg om grenprefikset kom fram, og det er ulike spørsmål.
Applikasjonsstien er igjen eit tredje spørsmål. Eit naboforhold distribuerer tilgjenge; det gir ikkje løyve gjennom brannmuren og beviser ikkje at trafikkveljarar og filtreringsreglar er samde. Verifiser den tillatne straumen og returvegen med ein godkjend test i staden for å anta at ruta inneber policyen.
Kva den ferdige samanlikninga bør registrera
Skriv ned tunnelgrensesnittet, versjonen som støttar det, kontrollutvekslinga du verifiserte, og rutepolicyen du avgrensa. Legg til multicast-innstillinga, fordi det er detaljen som stille avgjer om noko av resten verkar. Hald den registreringa ved sida av den utrulla versjonen, slik at ei seinare funksjonsendring kan gjennomgåast utan å starta på nytt frå ein føresetnad som sidan er gått ut.
Viss noko av dei fire manglar, har du ein preferanse og ikkje eit design. Rett først det manglande faktumet; protokollvalet er den enkle delen.