OSPF eller EIGRP over en ASA VTI: hvilken understøtter din version
OSPFv2 og EIGRP kører kun over en ASA VTI fra 9.19(1), og kun med multicast aktiveret. Sammenlign de to på den version, du kører, og verificér derefter naboerne.
De fleste OSPF-mod-EIGRP-diskussioner forudsætter, at tunnelen allerede kan bære protokollen, og på en ASA er netop den antagelse den del, der er værd at kontrollere først. Sammenligningen bliver først interessant, når image, VTI-type og multicast-sti er bekræftet. Tager du fejl af den rækkefølge, bruger du en eftermiddag på at tune timere på en tunnel, der aldrig danner et naboskab. Jeg starter hvert af disse designs med release notes og den kørende konfiguration, ikke med protokolpræferencen.
Versionen afgør før protokollen
Ciscos VTI-guide til ASA 9.24 er et brugbart dokumentationsgrundlag: den beskriver statiske og dynamiske VTI'er og oplister statisk routing, BGP, OSPF og EIGRP. Dens funktionshistorik placerer OSPFv2- og EIGRP-support på VTI ved 9.19(1). Alt ældre end det er en anden samtale.
Så de to første spørgsmål er kedelige og afgø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 |
Udsagnet om, at en ASA ikke kan bruge VTI'er eller ikke kan bære en IGP, var sandt for nogle ældre images og er ikke en aktuel supportmatrix. Ligesom 9.24-guiden ikke er en instruktion om at opgradere hver enhed. Den fortæller, hvad den version understøtter, og din udrullede version må svare for sig selv.
At unicast kommer igennem betyder ikke, at IGP'en dannes
Den samme guide bemærker, at unicast passerer som standard, og at multicast skal aktiveres for OSPFv2 eller EIGRP på VTI'en, med dokumenterede grænser for multicast-grupper. Den ene sætning forklarer de fleste mislykkede naboskaber, jeg har set på dette design. En ping, der virker gennem tunnelen, eller en grøn IPsec-status beviser kun unicast-stien. Protokolopdagelse kræver multicast-stien, og de to konfigureres separat.
Kontrollér tunnelinterface-konfigurationen for den multicast-indstilling, før du rører hello- eller hold-timere. Hvis indstillingen mangler, er naboskabet ikke langsomt, det er umuligt.
OSPF og EIGRP side om side på samme tunnel
På selve tunnelen ser de to protokoller ud som alle andre steder. OSPF har brug for en matchende netværkstype, område, godkendelse og nabo-parametre; EIGRP har brug for sit AS-nummer og de interface-niveau-indstillinger, der hører til.
Fælden er at kopiere naboerklæringer fra en anden tunnelmodel. Råd om statiske naboer i et design uden VTI fandtes for at undgå multicast, og de overføres ikke til en VTI, der forventes at bære protokollen naturligt. Konfigurér den understøttede interface-adfærd, og lad derefter protokollen danne sit eget naboskab.
Sammenlign derefter på de akser, der faktisk er forskellige for din topologi: interoperabilitet med den anden side, konvergensadfærd, du kan teste, og den driftsviden, dit team har. En historisk anekdote om, at den ene protokol er hurtigere eller lettere, er ikke en måling af dit netværk.
Naboer er ikke det samme som installerede ruter
Når naboskabet er oppe, skal du skelne det, der origineres, fra det, der accepteres. Se på, hvilke branch-prefixer hver side annoncerer, hvilke der modtages, hvilke der vælges, og hvilke der faktisk når routingtabellen. Import-, eksport- og redistributionsomfanget bør være bevidst i stedet for en samlet annoncering af alt, hvad enheden ved.
show ospf neighbor og show eigrp neighbors fortæller dig, at sessionen er levende. show route fortæller dig, om branch-prefixet nåede frem, og det er forskellige spørgsmål.
Applikationsstien er igen et tredje spørgsmål. Et naboskab distribuerer nåbarhed; det giver ikke tilladelse gennem firewallen, og det beviser ikke, at trafikvælgere og filtreringsregler er enige. Verificér den tilladte strøm og dens svarsti med en godkendt test i stedet for at antage, at ruten indebærer politikken.
Hvad den færdige sammenligning bør registrere
Skriv tunnelinterfacet ned, den version der understøtter det, den kontroludveksling, du verificerede, og den rutepolitik, du afgrænsede. Tilføj multicast-indstillingen, fordi det er den detalje, der stille afgør, om noget af resten virker. Opbevar den registrering ved siden af den udrullede version, så en senere funktionsændring kan gennemgås uden at starte fra en antagelse, der siden er udløbet.
Hvis blot en af de fire mangler, har du en præference frem for et design. Ret først den manglende kendsgerning; protokolvalget er den nemme del.