Failback na ASA: co se skutečně přesune, když se trasa vrátí
Návrat trasy na primární cestu neznamená, že se staré toky přesunuly. Sledujte společně uplink, tunel, tabulku spojení i výsledek aplikace.
Na ASA se dvěma uplinky není failback opakem failoveru. Trasa k peeru se změní a platforma pak musí sladit tři oddělené stavové stroje: routovací tabulku, bezpečnostní asociace IKE a IPsec a tabulku spojení. Každý může za ostatními zaostávat a právě toto zpoždění většina lidí popisuje jako tunel, který se nevrací.
Co failback skutečně mění
Vyhledání v routovací tabulce je viditelná část. Když se sledovaný objekt obnoví, sledovaná trasa k vnější adrese peeru se vrátí a další paket, který ASA odešle, jde znovu po primárním spoji. Všechno po tom závisí na tom, zda stávající stav odpovídá nové cestě.
ARP a NAT jsou tiché závislosti. Nový next hop potřebuje přeložitelnou bránu a překlad, který stále odpovídá vzdálené straně, jinak první pakety po failbacku nikam nedojdou a trasa vypadá v pořádku, zatímco nic nefunguje.
Čtyři pohledy na jedné časové ose
Zaznamenejte stejné čtyři věci před přechodem, během něj a po něm, protože jediný snímek vám neřekne, která vrstva se pohnula.
| 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 |
Trasa, která se nikdy nezměnila, a trasa, která se změnila, zatímco starší spojení si ponechalo svůj stav předávání, dávají stejnou stížnost a zcela odlišné důkazy.
Proč stará spojení zůstávají na záložní cestě
ASA neruší tok proto, že se změnila trasa. Navázaná spojení si drží rozhodnutí o předávání, se kterým byla vytvořena, a platforma nabízí samostatné ovládací prvky pro to, jak dlouho je to dovoleno: floating-connection timeout a connection holddown. Cisco Průvodce nastavením spojení v ASA 9.24 je bere jako odlišné otázky, a přesně tak se chovají. Jeden řídí přežití existujícího toku, druhý řídí, kdy nové toky smějí použít preferovanou cestu.
Před změnou kterékoli z nich si přečtěte platné hodnoty pro svou verzi. Snížení zavírá relace, které lidé stále používají. Zvýšení dělá z failbacku něco, co se nikdy nestalo, protože nová spojení po celou dobu chodí po staré cestě.
Tunel nepřegeneruje klíče proto, že se vrátila trasa
Bezpečnostní asociace IPsec nesou vlastní vyjednanou dobu života a přežívají změnu trasy, která je nesla. Tunel proto může zůstat vzhůru přes failback, i když jeho vnější adresování už neodpovídá používané cestě; to je argument pro DPD a pro návrhy, které adresu peeru fixují místo toho, aby ji nechaly plavat.
Návrhy s crypto-map a VTI se zde chovají jinak a dokumentace Cisco k 9.24 VTI popisuje variantu založenou na trasách. Staré paušální tvrzení, že ASA neumí VPN založené na trasách, pro podporované verze neplatí.
Čtěte důkazy v tomto pořadí
Začněte v řídicí rovině: show route pro zvolenou cestu, show interface pro stav spoje a čítače monitoru SLA pro sledovaný objekt. Pak přečtěte show crypto ikev2 sa, nebo ekvivalent pro IKEv1, abyste viděli, který peer je živý, a následně show crypto ipsec sa pro chráněné toky. Potom zužte tabulku spojení pomocí show conn address <host> a porovnejte sloupec rozhraní u starých a nových záznamů. Výstupy zapisujte s časovými značkami, protože jejich pořadí je diagnóza.
Skončete testem aplikace: jeden tok, který už existoval, a jeden vytvořený po návratu trasy. Pokud starý tok selže a nový funguje, máte příběh o stavu spojení. Pokud selžou oba, tunel nebo politika jsou špatné a tabulka spojení je rozptýlení.
Udržujte tento záznam ve stejném tvaru ve všech třech fázích a poznamenejte přesnou verzi. Když časová osa stále ukazuje na jediný přechod, pošlete záznam podpoře, místo abyste hádali ID chyby.