På en ASA med to uplinks er failback ikke det motsatte av failover. Ruten mot peer-en forandres, og deretter må plattformen bringe tre atskilte tilstandsmaskiner i samsvar: rutetabellen, IKE- og IPsec-sikkerhetsassosiasjonene og forbindelsestabellen. Hver av dem kan henge etter de andre, og det etterslepet er nettopp det folk flest kaller en tunnel som ikke kommer tilbake.

Hva failback egentlig forandrer

Ruteoppslaget er den synlige delen. Når det overvåkede objektet er friskt igjen, kommer den overvåkede ruten mot peer-ens ytre adresse tilbake, og den neste pakken ASA-en sender følger den primære forbindelsen på nytt. Alt etter dette avhenger av om den eksisterende tilstanden passer med den nye veien.

ARP og NAT er de stille avhengighetene. En ny next hop trenger en gateway som lar seg slå opp og en oversettelse som fortsatt passer mot den fjerne enden, ellers går de første pakkene etter failback ingen vei, og ruten ser sunn ut mens ingenting fungerer.

Fire perspektiver på én tidslinje

Noter de samme fire tingene før, under og etter overgangen, fordi et enkelt øyeblikksbilde ikke kan fortelle hvilket lag som flyttet seg.

ViewWhat to record
Uplink and routeInterface state, the tracked object result, the route selected for the outer peer address
IKE and IPsecThe live peer, IKE version, security associations, protected-traffic counters
Connection tableInterface and endpoint pair for old flows and for flows created after the change
ApplicationOne pre-existing operation and one fresh request, each marked success, reset, stall or recovered

En rute som aldri ble forandret, og en rute som ble forandret mens en eldre forbindelse beholdt videresendingstilstanden sin, gir samme klage og helt forskjellige bevis.

Hvorfor gamle forbindelser blir liggende på reserveveien

ASA-en river ikke ned en strøm fordi en rute er forandret. Opprettede forbindelser beholder videresendingsvalget de ble laget med, og plattformen tilbyr separate kontroller for hvor lenge det er tillatt: floating-connection timeout og connection holddown. Ciscos veiledning for forbindelsesinnstillinger i ASA 9.24 fra Cisco behandler dem som to forskjellige spørsmål, og det er nøyaktig slik de oppfører seg. Den ene styrer om en eksisterende strøm overlever, 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. Senker du dem, lukkes økter som folk fortsatt bruker. Hever du dem, ser failback ut som om den aldri skjedde, fordi nye forbindelser fortsetter å ta den gamle veien hele tiden.

En tunnel forhandler ikke nye nøkler bare fordi en rute kom tilbake

IPsec-sikkerhetsassosiasjoner bærer sin egen forhandlede levetid og overlever ruteendringen som bar dem. En tunnel kan derfor stå oppe gjennom en failback mens den ytre adresseringen ikke lenger passer med veien som brukes, og det er argumentet for DPD og for design som fester peer-adressen framfor å la den flyte.

Crypto-map- og VTI-oppsett oppfører seg annerledes her, og Ciscos dokumentasjon for 9.24 VTI beskriver det rutebaserte alternativet. Den gamle generelle påstanden om at en ASA ikke kan kjøre rutebaserte VPN-er, gjelder ikke for støttede versjoner.

Les bevisene i denne rekkefølgen

Start med kontrollplanet: show route for den valgte veien, show interface for koblingstilstand og tellerne i SLA-monitoren for det overvåkede objektet. Les deretter show crypto ikev2 sa, eller IKEv1-ekvivalenten, for å se hvilken peer som lever, fulgt av show crypto ipsec sa for de beskyttede strømmene. Deretter avgrenser du forbindelsestabellen med show conn address <host> og sammenligner 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 laget etter at ruten kom tilbake. Hvis den gamle strømmen feiler og den nye virker, har du en historie om forbindelsestilstand. Hvis begge feiler, er tunnelen eller policyen gal, og forbindelsestabellen er en avledning.

Hold den notatene i samme form gjennom alle tre fasene, og noter den nøyaktige versjonen. Når tidslinjen fortsetter å peke på én enkelt overgang, send notatene til support i stedet for å gjette på en bug-ID.

Relaterte artikler