OSPF eller EIGRP över en ASA VTI: vilken din version stöder
OSPFv2 och EIGRP går över en ASA VTI först från 9.19(1), och bara med multicast aktiverat. Jämför de två på den version du kör och verifiera sedan grannarna.
De flesta OSPF-mot-EIGRP-diskussioner förutsätter att tunneln redan kan bära protokollet, och på en ASA är just den förutsättningen den del som är värd att kontrollera först. Jämförelsen blir intressant först efter att image, VTI-typ och multicast-väg har bekräftats. Tar du fel i den ordningen spenderar du en eftermiddag med att justera timers på en tunnel som aldrig kommer att bilda en grannrelation. Jag börjar varje sådant här designarbete med release notes och den körande konfigurationen, inte med protokollpreferensen.
Versionen avgör före protokollet
Ciscos VTI-guide för ASA 9.24 är en användbar dokumentationsbas: den beskriver statiska och dynamiska VTI:er och listar statisk routing, BGP, OSPF och EIGRP. Dess funktionshistorik placerar stöd för OSPFv2 och EIGRP på VTI vid 9.19(1). Allt äldre än så är ett annat samtal.
Så de två första frågorna är tråkiga och avgörande:
| 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åståendet att en ASA inte kan använda VTI:er eller inte kan bära en IGP var sant för vissa äldre images och är inte en aktuell supportmatris. På samma sätt är 9.24-guiden inte en instruktion att uppgradera varje enhet. Den berättar vad den versionen stöder, och din driftsatta version måste svara för sig själv.
Att unicast passerar betyder inte att IGP:n bildas
Samma guide noterar att unicast passerar som standard och att multicast måste aktiveras för OSPFv2 eller EIGRP på VTI:n, med dokumenterade gränser för multicast-grupper. Den enda meningen förklarar de flesta misslyckade grannrelationer jag har sett i den här designen. En ping som fungerar genom tunneln, eller en grön IPsec-status, bevisar bara unicast-vägen. Protokollupptäckt behöver multicast-vägen, och de två konfigureras separat.
Kontrollera tunnelgränssnittets konfiguration för den multicast-inställningen innan du rör hello- eller hold-timers. Om inställningen saknas är grannrelationen inte långsam, den är omöjlig.
OSPF och EIGRP sida vid sida på samma tunnel
På själva tunneln ser de två protokollen ut som de gör någon annanstans. OSPF behöver en matchande nätverkstyp, område, autentisering och grannparametrar; EIGRP behöver sitt AS-nummer och de inställningar på gränssnittsnivå som hör till.
Fällan är att kopiera grannkommandon från en annan tunnelmodell. Råd om statiska grannar i en design utan VTI fanns för att undvika multicast, och de överförs inte till en VTI som förväntas bära protokollet inbyggt. Konfigurera det stödda gränssnittsbeteendet och låt sedan protokollet bilda sin egen grannrelation.
Jämför sedan på de axlar som faktiskt skiljer sig för din topologi: interoperabilitet med andra sidan, konvergensbeteende du kan testa och driftkunskapen i ditt team. En historisk anekdot om att det ena protokollet är snabbare eller lättare är inte en mätning av ditt nät.
Grannar är inte samma sak som installerade rutter
När grannrelationen är uppe, skilj på det som origineras och det som accepteras. Titta på vilka grenprefix varje sida annonserar, vilka som tas emot, vilka som väljs och vilka som faktiskt når routingtabellen. Omfattningen för import, export och redistribuering bör vara medveten i stället för en samlad annonsering av allt enheten vet.
show ospf neighbor och show eigrp neighbors berättar att sessionen lever. show route berättar om grenprefixet kom fram, och det är olika frågor.
Applikationsvägen är återigen en tredje fråga. En grannrelation distribuerar nåbarhet; den ger inte tillstånd genom brandväggen och bevisar inte att trafikväljare och filterregler stämmer överens. Verifiera det tillåtna flödet och dess returväg med ett godkänt test i stället för att anta att rutten innebär policyn.
Vad den färdiga jämförelsen bör registrera
Skriv ned tunnelgränssnittet, versionen som stöder det, kontrollutbytet du verifierade och den rutpolicy du avgränsade. Lägg till multicast-inställningen, eftersom det är detaljen som tyst avgör om något av resten fungerar. Förvara den registreringen bredvid den driftsatta versionen så att en senare funktionsändring kan granskas utan att börja om från en förutsättning som sedan dess har löpt ut.
Om något av de fyra saknas har du en preferens och inte en design. Rätta först det saknade faktumet; protokollvalet är den lätta delen.