Failback a l'ASA: què es mou realment quan torna la ruta
Que una ruta torni a la primària no vol dir que els fluxos antics s'hagin mogut. Mireu alhora l'uplink, el túnel, la taula de connexions i el resultat de l'aplicació.
En una ASA amb dos uplinks, el failback no és el revés del failover. La ruta cap al peer canvia i, després, la plataforma ha de reconciliar tres màquines d'estat separades: la taula de rutes, les associacions de seguretat IKE i IPsec i la taula de connexions. Cadascuna pot quedar-se enrere respecte de les altres, i aquest retard és el que la majoria de la gent descriu com un túnel que no torna.
Què canvia realment el failback
La consulta de la ruta és la part visible. Quan l'objecte monitorat es recupera, la ruta monitorada cap a l'adreça exterior del peer torna, i el següent paquet que envia l'ASA segueix de nou l'enllaç primari. Tot el que ve després depèn de si l'estat existent concorda amb el camí nou.
ARP i NAT són les dependències silencioses. Un next hop nou necessita una passarel·la resoluble i una traducció que encara encaixi amb l'extrem remot; si no, els primers paquets després del failback no van enlloc i la ruta sembla correcta mentre res no funciona.
Quatre perspectives en una sola línia temporal
Registreu les mateixes quatre coses abans, durant i després de la transició, perquè una sola instantània no us pot dir quina capa s'ha mogut.
| 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 |
Una ruta que no va canviar mai i una ruta que va canviar mentre una connexió més antiga conservava el seu estat de reenviament produeixen la mateixa queixa i proves completament diferents.
Per què les connexions antigues es queden al camí de reserva
L'ASA no desmunta un flux perquè hagi canviat una ruta. Les connexions establertes conserven la decisió de reenviament amb què es van crear, i la plataforma ofereix controls separats per a quant de temps es permet això: floating-connection timeout i connection holddown. Guia de configuració de connexions de l'ASA 9.24 de Cisco els tracta com a qüestions diferents, i és exactament com es comporten. Un governa la supervivència d'un flux existent; l'altre governa quan els fluxos nous poden usar el camí preferit.
Llegiu els valors efectius de la vostra versió abans de canviar cap dels dos. Baixar-los tanca sessions que la gent encara fa servir. Apujar-los fa que el failback sembli que no va passar mai, perquè les connexions noves continuen agafant el camí antic durant tot el temps.
Un túnel no regenera claus perquè hagi tornat una ruta
Les associacions de seguretat IPsec porten la seva pròpia vida negociada i sobreviuen al canvi de ruta que les transportava. Per tant, un túnel pot quedar-se aixecat durant un failback mentre el seu adreçament exterior ja no coincideix amb el camí en ús, que és l'argument a favor de DPD i dels dissenys que fixen l'adreça del peer en lloc de deixar-la flotant.
Els dissenys amb crypto-map i VTI es comporten aquí d'una altra manera, i la documentació de Cisco per a 9.24 VTI descriu l'opció basada en rutes. L'antiga afirmació general que una ASA no pot executar VPN basades en rutes no val per a les versions suportades.
Llegiu les proves en aquest ordre
Comenceu pel pla de control: show route per al camí seleccionat, show interface per a l'estat de l'enllaç i els comptadors del monitor SLA per a l'objecte monitorat. Després llegiu show crypto ikev2 sa, o l'equivalent IKEv1, per veure quin peer és viu, seguit de show crypto ipsec sa per als fluxos protegits. A continuació estrenyeu la taula de connexions amb show conn address <host> i compareu la columna d'interfície entre les entrades antigues i les noves. Anoteu les sortides amb marques de temps, perquè el seu ordre és el diagnòstic.
Acabeu amb una prova d'aplicació: un flux que ja existia i un altre creat després que tornés la ruta. Si el flux antic falla i el nou funciona, teniu una història d'estat de connexió. Si fallen tots dos, el túnel o la política són dolents i la taula de connexions és una distracció.
Mantingueu aquest registre amb la mateixa forma a les tres fases i anoteu la versió exacta. Quan la línia temporal apunti sempre a una sola transició, envieu el registre a suport en lloc d'endevinar un ID d'error.