Failback på ASA: hvad der faktisk flytter sig, når ruten vender tilbage
At ruten vender tilbage til den primære forbindelse betyder ikke, at gamle flows er flyttet. Se på uplink, tunnel, forbindelsestabellen og appens resultat sammen.
På en ASA med to uplinks er failback ikke det omvendte af failover. Ruten til peer'en ændres, og derefter skal platformen forlige tre adskilte tilstandsmaskiner: rutetabellen, IKE- og IPsec-sikkerhedsassociationer og forbindelsestabellen. Hver af dem kan sakke bagud efter de andre, og netop den forsinkelse er det, de fleste beskriver som en tunnel, der ikke kommer tilbage.
Hvad failback faktisk ændrer
Ruteopslaget er den synlige del. Når det overvågede objekt kommer sig, vender den overvågede rute til peer'ens ydre adresse tilbage, og den næste pakke, ASA'en sender, følger igen det primære link. Alt derefter afhænger af, om den eksisterende tilstand stemmer med den nye vej.
ARP og NAT er de stille afhængigheder. Et nyt next hop kræver en gateway, der kan opløses, og en oversættelse, der stadig passer til den fjerne ende, ellers går de første pakker efter failback ingen steder hen, og ruten ser fin ud, mens intet virker.
Fire visninger på én tidslinje
Registrér de samme fire ting før, under og efter overgangen, fordi et enkelt øjebliksbillede ikke kan fortælle, hvilket lag der flyttede 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 rute, der aldrig blev ændret, og en rute, der blev ændret, mens en ældre forbindelse beholdt sin videresendelsestilstand, giver samme klage og helt forskellig evidens.
Hvorfor gamle forbindelser bliver på backup-vejen
ASA'en river ikke et flow ned, fordi en rute blev ændret. Etablerede forbindelser beholder den videresendelsesbeslutning, de blev oprettet med, og platformen har separate kontroller for, hvor længe det er tilladt: floating-connection timeout og connection holddown. Ciscos Ciscos vejledning til forbindelsesindstillinger i ASA 9.24 behandler dem som forskellige spørgsmål, og det er præcis sådan, de opfører sig. Den ene styrer overlevelsen af et eksisterende flow, den anden styrer, hvornår nye flows må bruge den foretrukne vej.
Læs de gældende værdier for din version, før du ændrer nogen af dem. Sænkes de, lukkes sessioner, som folk stadig bruger. Hæves de, ser failback ud, som om det aldrig skete, fordi nye forbindelser bliver ved med at tage den gamle vej i hele perioden.
En tunnel gennemslår ikke nøgler, fordi en rute kom tilbage
IPsec-sikkerhedsassociationer har deres egen forhandlede levetid og overlever den ruteændring, der bar dem. En tunnel kan derfor blive oppe gennem et failback, mens dens ydre adressering ikke længere passer til den anvendte vej, og det er argumentet for DPD og for designs, der fastlåser peer-adressen i stedet for at lade den flyde.
Design med crypto-map og VTI opfører sig anderledes her, og Ciscos dokumentation for 9.24 VTI beskriver den rutbaserede mulighed. Den gamle generelle påstand om, at en ASA ikke kan køre rutbaserede VPN'er, holder ikke for understøttede versioner.
Læs evidensen i denne rækkefølge
Begynd med kontrolplanet: show route for den valgte vej, show interface for linktilstand og SLA-monitorens tællere for det overvågede objekt. Læs derefter show crypto ikev2 sa, eller IKEv1-ækvivalenten, for at se, hvilken peer der er levende, efterfulgt af show crypto ipsec sa for de beskyttede flows. Indsnævr så forbindelsestabellen med show conn address <host>, og sammenlign interface-kolonnen for gamle og nye poster. Skriv outputtet ned med tidsstempler, fordi deres rækkefølge er diagnosen.
Slut af med en applikationstest: et flow, der allerede eksisterede, og et, der blev oprettet, efter at ruten kom tilbage. Hvis det gamle flow fejler, og det nye virker, har du en historie om forbindelsestilstand. Hvis begge fejler, er tunnelen eller politikken forkert, og forbindelsestabellen er en distraktion.
Hold den registrering i samme form gennem alle tre faser, og noter den nøjagtige version. Når tidslinjen bliver ved med at pege på en enkelt overgang, send registreringen til support i stedet for at gætte på et bug-ID.