Failback på ASA: kva som faktisk flyttar seg når ruta kjem tilbake

På ein ASA med to uplink er failback ikkje det motsette av failover. Ruta til peer-en blir endra, og etterpå må plattforma sameina tre skilde tilstandsmaskinar: rutetabellen, IKE- og IPsec-tryggleiksassosiasjonane og sambandstabellen. Kvar av dei kan hamne bak dei andre, og nettopp den forseinkinga er det folk flest skildrar som ein tunnel som ikkje kjem tilbake.

Kva failback faktisk endrar

Ruteoppslaget er den synlege delen. Når det overvaka objektet kjem seg, kjem den overvaka ruta til den ytre adressa til peer-en tilbake, og den neste pakken ASA-en sender følgjer den primære lenkja igjen. Alt etterpå er avhengig av om den eksisterande tilstanden stemmer med den nye vegen.

ARP og NAT er dei stille avhengnadene. Eit nytt next hop treng ein gateway som kan løysast opp og ei omsetjing som framleis passar til den fjerne enden, elles går dei fyrste pakkane etter failback ingen stad, og ruta ser fin ut medan ingenting verkar.

Fire visningar på éi tidslinje

Registrer dei same fire tinga før, under og etter overgangen, fordi eitt augeblinksbilete ikkje kan seie kva lag som flytta seg.

Ei rute som aldri vart endra, og ei rute som vart endra medan eit eldre samband heldt på vidaresendingstilstanden sin, gjev same klaga og heilt ulike prov.

Kvifor gamle samband blir verande på reservevegen

ASA-en riv ikkje ned ein straum fordi ei rute vart endra. Etablerte samband held på vidaresendingsavgjerda dei vart oppretta med, og plattforma har skilde kontrollar for kor lenge det er tillate: floating-connection timeout og connection holddown. rettleiinga til Cisco for sambandsinnstillingar i ASA 9.24 frå Cisco handsamar dei som to ulike spørsmål, og det er nøyaktig slik dei oppfører seg. Den eine styrer overlevinga til ein eksisterande straum, den andre styrer når nye straumar kan bruke den føretrekte vegen.

Les dei gjeldande verdiane for versjonen din før du endrar nokon av dei. Søkkjer du dei, blir økter som folk framleis brukar lukka. Aukar du dei, ser failback ut som om det aldri hende, fordi nye samband held fram med å ta den gamle vegen heile perioden.

Ein tunnel forhandlar ikkje nye nøklar fordi ei rute kom tilbake

IPsec-tryggleiksassosiasjonar ber sin eigen forhandla levetid og overlever ruteendringa som bar dei. Ein tunnel kan difor bli ståande gjennom ein failback medan den ytre adresseringa ikkje lenger passar til vegen som blir brukt, og det er argumentet for DPD og for design som festar peer-adressa i staden for å la ho flyte.

Crypto-map- og VTI-design oppfører seg annleis her, og dokumentasjonen til Cisco for 9.24 VTI skildrar det rutebaserte alternativet. Den gamle generelle påstanden om at ein ASA ikkje kan køyre rutebaserte VPN-ar, held ikkje for støtta versjonar.

Les prova i denne rekkjefølgja

Byrja med kontrollplanet: show route for den valde vegen, show interface for lenkjetilstand og teljarane til SLA-monitoren for det overvaka objektet. Les så show crypto ikev2 sa, eller IKEv1-ekvivalenten, for å sjå kva peer som lever, etterfølgt av show crypto ipsec sa for dei verna straumane. Snevre så inn sambandstabellen med show conn address <host> og samanlikn interface-kolonnen for gamle og nye oppføringar. Skriv ned utdataa med tidsstempel, fordi rekkjefølgja deira er diagnosen.

Avslutt med ein applikasjonstest: ein straum som allereie fanst, og ein som vart oppretta etter at ruta kom tilbake. Viss den gamle straumen feilar og den nye verkar, har du ei forteljing om sambandstilstand. Viss båe feilar, er tunnelen eller policyen feil, og sambandstabellen er ein distraksjon.

Hald den registreringa i same form gjennom alle tre fasane, og noter den nøyaktige versjonen. Når tidslinja held fram med å peike på éin einaste overgang, send registreringa til support i staden for å gjete på ein bug-ID.