Failback á ASA: hvað hreyfist í raun þegar leiðin kemur aftur
Að leið komi aftur á aðalleiðina þýðir ekki að gömlu flæðin hafi færst. Skoðaðu uplink, göngin, tengitöfluna og niðurstöðu forritsins saman.
Á ASA með tvo uplink er failback ekki andhverfa failover. Leiðin að peer breytist, og síðan þarf pallurinn að samræma þrjár aðskildar stöðuvélar: leiðatöfluna, IKE- og IPsec-öryggistengslin og tengitöfluna. Hver þeirra getur dregist aftur úr hinum, og einmitt sú seinkun er það sem flestir lýsa sem göngum sem koma ekki aftur.
Hvað failback breytir í raun
Leitarvinnsla leiðarinnar er sýnilegi hlutinn. Þegar fylgst hlutur nær sér aftur kemur fylgda leiðin að ytri vistfangi peersins aftur, og næsta pakki sem ASA sendir fer aftur um aðaltengið. Allt sem á eftir kemur veltur á því hvort fyrirliggjandi staða stemmir við nýju leiðina.
ARP og NAT eru hljóðlátu háðin. Nýr next hop þarf leysanlegt hlið og þýðingu sem passar enn við fjarlæga endann, annars fara fyrstu pakkarnir eftir failback hvergi og leiðin virðist í lagi á meðan ekkert virkar.
Fjögur sjónarhorn á einni tímalínu
Skráðu sömu fjóra hlutina fyrir, á meðan og eftir umskiptin, því eitt augnabliksmynd getur ekki sagt þér hvaða lag hreyfðist.
| 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 |
Leið sem breyttist aldrei og leið sem breyttist á meðan eldri tenging hélt sendingarstöðu sinni gefa sömu kvörtun og gjörólík sönnunargögn.
Hvers vegna gömul tenging hanga á varaleiðinni
ASA rífur ekki flæði vegna þess að leið breyttist. Komin tenging halda sendingarákvörðuninni sem þau voru búin til með, og pallurinn býður aðskildar stýringar fyrir hversu lengi það er leyft: floating-connection timeout og connection holddown. Leiðarvísir um tengistillingar ASA 9.24 Cisco meðhöndlar þau sem aðskildar spurningar, og nákvæmlega þannig hegða þau sér. Annað stýrir því að fyrirliggjandi flæði lifi, hitt hvenær ný flæði mega nota ákjósanlegu leiðina.
Lestu gildandi gildin fyrir þína útgáfu áður en þú breytir hvoru sem er. Lækkun lokar lotum sem fólk er enn að nota. Hækkun lætur failback líta út eins og það hafi aldrei átt sér stað, því nýjar tengingar taka áfram gömlu leiðina allan tímann.
Göng endursemja ekki lykla af því að leið kom aftur
IPsec-öryggistengsl bera eigin samsemið líftíma og lifa af leiðabreytinguna sem bar þau. Göng geta því staðið yfir failback á meðan ytri vistföng þeirra passa ekki lengur við leiðina sem er í notkun, og það er röksemdin fyrir DPD og hönnun sem festir vistfang peersins í stað þess að láta það fljóta.
Crypto-map- og VTI-hönnun haga sér öðruvísi hér, og skjöl Cisco fyrir 9.24 VTI lýsa leiðamiðuðum valkosti. Gamla almenna fullyrðingin um að ASA geti ekki keyrt leiðamiðuð VPN gildir ekki fyrir studdar útgáfur.
Lestu sönnunargögnin í þessari röð
Byrjaðu á stýrisléttunni: show route fyrir valda leið, show interface fyrir stöðu tengils og teljara SLA-vaktarinnar fyrir fylgdan hlut. Lestu síðan show crypto ikev2 sa, eða IKEv1-jafngildið, til að sjá hvaða peer er lifandi, og því næst show crypto ipsec sa fyrir varin flæði. Þrengdu síðan tengitöfluna með show conn address <host> og berðu saman viðmótsdálkinn í gömlum og nýjum færslum. Skrifaðu niðurstöðurnar niður með tímasetningum, því röðin er greiningin.
Endaðu á prófun forrits: eitt flæði sem var þegar til og eitt sem var búið til eftir að leiðin kom aftur. Ef gamla flæðið bregst og það nýja virkar hefur þú sögu um tengistöðu. Ef bæði bregðast er göngin eða stefnan röng og tengitaflan er truflun.
Haltu þeirri skrá í sama formi á öllum þremur stigum og skráðu nákvæma útgáfu. Þegar tímalínan heldur áfram að benda á eitt umskipti skaltu senda skrána til stuðnings í stað þess að giska á villunúmer.