Failback på ASA: vad som faktiskt flyttar sig när rutten kommer tillbaka
Att en rutt går tillbaka till den primära förbindelsen betyder inte att gamla flöden har flyttat. Titta på uplink, tunnel, förbindelsetabellen och appresultatet tillsammans.
På en ASA med två uplinks är failback inte motsatsen till failover. Rutten till peer-en ändras, och därefter måste plattformen förena tre separata tillståndsmaskiner: rutttabellen, IKE- och IPsec-säkerhetsassociationerna och förbindelsetabellen. Var och en kan hamna efter de andra, och det eftersläpet är precis det folk beskriver som en tunnel som inte kommer tillbaka.
Vad failback faktiskt ändrar
Ruttuppslaget är den synliga delen. När det övervakade objektet återhämtar sig kommer den övervakade rutten till peer-ens yttre adress tillbaka, och nästa paket som ASA:n skickar följer den primära länken igen. Allt efteråt beror på om det befintliga tillståndet stämmer med den nya vägen.
ARP och NAT är de tysta beroendena. Ett nytt next hop behöver en gateway som går att slå upp och en översättning som fortfarande passar den bortre änden, annars går de första paketen efter failback ingenstans och rutten ser bra ut medan ingenting fungerar.
Fyra vyer på en enda tidslinje
Registrera samma fyra saker före, under och efter övergången, eftersom en enda ögonblicksbild inte kan säga vilket lager som flyttade sig.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
En rutt som aldrig ändrades och en rutt som ändrades medan en äldre förbindelse behöll sitt vidarebefordringstillstånd ger samma klagomål och helt olika bevis.
Varför gamla förbindelser stannar på reservvägen
ASA:n river inte ned ett flöde för att en rutt ändrades. Upprättade förbindelser behåller vidarebefordringsbeslutet de skapades med, och plattformen erbjuder separata kontroller för hur länge det är tillåtet: floating-connection timeout och connection holddown. Ciscos vägledning för anslutningsinställningar i ASA 9.24 från Cisco behandlar dem som olika frågor, och det är precis så de beter sig. Den ena styr överlevnaden för ett befintligt flöde, den andra när nya flöden får använda den föredragna vägen.
Läs de gällande värdena för din version innan du ändrar någon av dem. Sänks de stängs sessioner som folk fortfarande använder. Höjs de ser failback ut som om det aldrig hände, eftersom nya förbindelser fortsätter att ta den gamla vägen hela tiden.
En tunnel förhandlar inte om nycklar för att en rutt kom tillbaka
IPsec-säkerhetsassociationer bär sin egen förhandlade livslängd och överlever den ruttändring som bar dem. En tunnel kan därför stå uppe genom en failback medan dess yttre adressering inte längre passar den väg som används, och det är argumentet för DPD och för designer som fäster peer-adressen i stället för att låta den flyta.
Crypto-map- och VTI-designer beter sig annorlunda här, och Ciscos dokumentation för 9.24 VTI beskriver det ruttbaserade alternativet. Det gamla generella påståendet att en ASA inte kan köra ruttbaserade VPN:er gäller inte för versioner som stöds.
Läs bevisen i den här ordningen
Börja med kontrollplanet: show route för den valda vägen, show interface för länkstatus och SLA-monitorns räknare för det övervakade objektet. Läs sedan show crypto ikev2 sa, eller IKEv1-motsvarigheten, för att se vilken peer som lever, följt av show crypto ipsec sa för de skyddade flödena. Avgränsa sedan förbindelsetabellen med show conn address <host> och jämför interface-kolumnen för gamla och nya poster. Skriv ned utdata med tidsstämplar, eftersom deras ordning är diagnosen.
Avsluta med ett applikationstest: ett flöde som redan fanns och ett som skapades efter att rutten kom tillbaka. Om det gamla flödet misslyckas och det nya fungerar har du en berättelse om förbindelsetillstånd. Om båda misslyckas är tunneln eller policyn fel och förbindelsetabellen är en distraktion.
Håll den registreringen i samma form genom alla tre faserna och notera den exakta versionen. När tidslinjen fortsätter att peka på en enda övergång, skicka registreringen till supporten i stället för att gissa ett bugg-ID.