OSPF eller EIGRP over en ASA VTI: hvilken støtter versjonen din
OSPFv2 og EIGRP går over en ASA VTI først fra 9.19(1), og bare med multicast aktivert. Sammenlign de to på versjonen du kjører, og kontroller deretter naboene.
De fleste OSPF-mot-EIGRP-diskusjoner forutsetter at tunnelen allerede kan bære protokollen, og på en ASA er nettopp den forutsetningen den delen som er verdt å kontrollere først. Sammenligningen blir først interessant etter at image, VTI-type og multicast-sti er bekreftet. Tar du feil av den rekkefølgen, bruker du en ettermiddag på å justere timere på en tunnel som aldri vil danne et naboskap. Jeg starter hvert av disse designene med utgivelsesnotatene og den kjørende konfigurasjonen, ikke med protokollpreferansen.
Versjonen avgjør før protokollen
Ciscos VTI-veiledning for ASA 9.24 er et brukbart dokumentasjonsgrunnlag: den beskriver statiske og dynamiske VTI-er og lister statisk ruting, BGP, OSPF og EIGRP. Funksjonshistorikken plasserer OSPFv2- og EIGRP-støtte på VTI ved 9.19(1). Alt eldre enn det er en annen samtale.
Så de to første spørsmålene er kjedelige og avgjørende:
| 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 en ASA ikke kan bruke VTI-er eller ikke kan bære en IGP, var sann for noen eldre images og er ikke en gjeldende støttematrise. På samme måte er ikke 9.24-veiledningen en instruks om å oppgradere hver enhet. Den forteller hva den versjonen støtter, og din utrullede versjon må svare for seg selv.
At unicast slipper gjennom betyr ikke at IGP-en dannes
Den samme veiledningen bemerker at unicast passerer som standard, og at multicast må aktiveres for OSPFv2 eller EIGRP på VTI-en, med dokumenterte grenser for multicast-grupper. Den ene setningen forklarer de fleste mislykkede naboskapene jeg har sett på dette designet. En ping som virker gjennom tunnelen, eller en grønn IPsec-status, beviser bare unicast-stien. Protokolloppdagelse trenger multicast-stien, og de to konfigureres separat.
Kontroller tunnelgrensesnitt-konfigurasjonen for den multicast-innstillingen før du rører hello- eller hold-timere. Hvis innstillingen mangler, er naboskapet ikke tregt, det er umulig.
OSPF og EIGRP side om side på samme tunnel
På selve tunnelen ser de to protokollene ut som de gjør ellers. OSPF trenger en samsvarende nettverkstype, område, autentisering og nabo-parametere; EIGRP trenger sitt AS-nummer og innstillingene på grensesnittnivå som hører til.
Fellen er å kopiere nabooppsett fra en annen tunnelmodell. Råd om statiske naboer i et design uten VTI fantes for å unngå multicast, og de overføres ikke til en VTI som forventes å bære protokollen naturlig. Konfigurer den støttede grensesnittatferden, og la deretter protokollen danne sitt eget naboskap.
Sammenlign deretter på aksene som faktisk er forskjellige for topologien din: interoperabilitet med den andre siden, konvergensatferd du kan teste, og driftskunnskapen i teamet ditt. En historisk anekdote om at den ene protokollen er raskere eller lettere, er ikke en måling av nettverket ditt.
Naboer er ikke det samme som installerte ruter
Når naboskapet er oppe, skill det som origineres fra det som aksepteres. Se på hvilke grenprefikser hver side annonserer, hvilke som mottas, hvilke som velges, og hvilke som faktisk når rutetabellen. Omfanget av import, eksport og redistribusjon bør være bevisst i stedet for en samlet annonsering av alt enheten vet.
show ospf neighbor og show eigrp neighbors forteller deg at sesjonen er levende. show route forteller deg om grenprefikset kom frem, og det er forskjellige spørsmål.
Applikasjonsstien er igjen et tredje spørsmål. Et naboforhold distribuerer tilgjengelighet; det gir ikke tillatelse gjennom brannmuren og beviser ikke at trafikkvelgere og filtreringsregler er enige. Verifiser den tillatte strømmen og returveien med en godkjent test i stedet for å anta at ruten innebærer policyen.
Hva den ferdige sammenligningen bør registrere
Skriv ned tunnelgrensesnittet, versjonen som støtter det, kontrollutvekslingen du verifiserte, og rutepolicyen du avgrenset. Legg til multicast-innstillingen, fordi det er detaljen som stille avgjør om noe av resten virker. Hold den registreringen ved siden av den utrullede versjonen, slik at en senere funksjonsendring kan gjennomgås uten å starte på nytt fra en forutsetning som siden er utløpt.
Hvis noe av de fire mangler, har du en preferanse og ikke et design. Rett først det manglende faktum; protokollvalget er den enkle delen.