Failback på ASA: hva som faktisk flytter seg når ruten kommer tilbake
At ruten går tilbake til den primære forbindelsen betyr ikke at gamle strømmer er flyttet. Se på uplink, tunnel, tilkoblingstabellen og appresultatet sammen.
På en ASA med to uplinks er failback ikke det motsatte av failover. Ruten til peer-en endres, og deretter må plattformen forene tre adskilte tilstandsmaskiner: rutetabellen, IKE- og IPsec-sikkerhetsassosiasjonene og tilkoblingstabellen. Hver av dem kan henge etter de andre, og nettopp den forsinkelsen er det folk flest beskriver som en tunnel som ikke kommer tilbake.
Hva failback faktisk endrer
Ruteoppslaget er den synlige delen. Når det overvåkede objektet kommer seg, kommer den overvåkede ruten til peer-ens ytre adresse tilbake, og den neste pakken ASA-en sender følger den primære lenken igjen. Alt etterpå avhenger av om den eksisterende tilstanden stemmer med den nye veien.
ARP og NAT er de stille avhengighetene. Et nytt next hop trenger en gateway som kan løses opp og en oversettelse som fortsatt passer til den fjerne enden, ellers går de første pakkene etter failback ingen steder, og ruten ser fin ut mens ingenting virker.
Fire visninger på én tidslinje
Registrer de samme fire tingene før, under og etter overgangen, fordi et enkelt øyeblikksbilde ikke kan si hvilket lag som flyttet seg.
| 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 rute som aldri ble endret, og en rute som ble endret mens en eldre tilkobling beholdt videresendingstilstanden sin, gir samme klage og helt forskjellige bevis.
Hvorfor gamle tilkoblinger blir på reserveveien
ASA-en river ikke ned en strøm fordi en rute ble endret. Etablerte tilkoblinger beholder videresendingsbeslutningen de ble opprettet med, og plattformen har separate kontroller for hvor lenge det er tillatt: floating-connection timeout og connection holddown. Ciscos Ciscos veiledning for tilkoblingsinnstillinger i ASA 9.24 behandler dem som forskjellige spørsmål, og det er nøyaktig slik de oppfører seg. Den ene styrer overlevelsen til en eksisterende strøm, den andre styrer når nye strømmer kan bruke den foretrukne veien.
Les de gjeldende verdiene for din versjon før du endrer noen av dem. Senkes de, lukkes økter som folk fortsatt bruker. Økes de, ser failback ut som om det aldri skjedde, fordi nye tilkoblinger fortsetter å ta den gamle veien i hele perioden.
En tunnel reforhandler ikke nøkler fordi en rute kom tilbake
IPsec-sikkerhetsassosiasjoner har sin egen forhandlede levetid og overlever ruteendringen som bar dem. En tunnel kan derfor bli stående gjennom et failback mens den ytre adresseringen ikke lenger passer til veien som brukes, og det er argumentet for DPD og for design som fester peer-adressen i stedet for å la den flyte.
Crypto-map- og VTI-design oppfører seg annerledes her, og Ciscos dokumentasjon for 9.24 VTI beskriver det rutbaserte alternativet. Den gamle generelle påstanden om at en ASA ikke kan kjøre rutbaserte VPN-er, holder ikke for støttede versjoner.
Les bevisene i denne rekkefølgen
Begynn med kontrollplanet: show route for den valgte veien, show interface for lenketilstand og SLA-monitorens tellere for det overvåkede objektet. Les deretter show crypto ikev2 sa, eller IKEv1-ekvivalenten, for å se hvilken peer som lever, etterfulgt av show crypto ipsec sa for de beskyttede strømmene. Snevre så inn tilkoblingstabellen med show conn address <host> og sammenlign interface-kolonnen for gamle og nye oppføringer. Skriv ned utdataene med tidsstempler, fordi rekkefølgen deres er diagnosen.
Avslutt med en applikasjonstest: én strøm som allerede fantes, og én som ble opprettet etter at ruten kom tilbake. Hvis den gamle strømmen feiler og den nye virker, har du en historie om tilkoblingstilstand. Hvis begge feiler, er tunnelen eller policyen feil, og tilkoblingstabellen er en distraksjon.
Hold den registreringen i samme form gjennom alle tre fasene, og noter den nøyaktige versjonen. Når tidslinjen fortsetter å peke på én enkelt overgang, send registreringen til support i stedet for å gjette på en bug-ID.