Failback en la ASA: qué se mueve realmente cuando vuelve la ruta
Que una ruta vuelva a la primaria no significa que los flujos antiguos se hayan movido. Observe juntos el uplink, el túnel, la tabla de conexiones y el resultado de la aplicación.
En una ASA con dos uplinks, el failback no es la inversa del failover. La ruta hacia el peer cambia y, después, la plataforma tiene que reconciliar tres máquinas de estado separadas: la tabla de rutas, las asociaciones de seguridad IKE e IPsec y la tabla de conexiones. Cada una puede quedarse atrás respecto de las demás, y ese retraso es lo que la mayoría de la gente describe como un túnel que no vuelve.
Qué cambia realmente el failback
La consulta de la ruta es la parte visible. Cuando el objeto monitorizado se recupera, la ruta monitorizada hacia la dirección exterior del peer regresa, y el siguiente paquete que envía la ASA vuelve a seguir el enlace primario. Todo lo que viene después depende de si el estado existente concuerda con el camino nuevo.
ARP y NAT son las dependencias silenciosas. Un next hop nuevo necesita una puerta de enlace resoluble y una traducción que siga encajando con el extremo remoto; si no, los primeros paquetes tras el failback no van a ninguna parte y la ruta parece correcta mientras nada funciona.
Cuatro vistas en una sola línea de tiempo
Registre las mismas cuatro cosas antes, durante y después de la transición, porque una sola instantánea no puede decirle qué capa se movió.
| 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 nunca cambió y una ruta que cambió mientras una conexión más antigua conservaba su estado de reenvío producen la misma queja y pruebas completamente distintas.
Por qué las conexiones antiguas se quedan en la ruta de respaldo
La ASA no derriba un flujo porque haya cambiado una ruta. Las conexiones establecidas conservan la decisión de reenvío con la que se crearon, y la plataforma ofrece controles separados para cuánto tiempo se permite eso: floating-connection timeout y connection holddown. La Guía de configuración de conexiones de la ASA 9.24 de Cisco los trata como preguntas distintas, y es exactamente como se comportan. Uno gobierna la supervivencia de un flujo existente; el otro, cuándo pueden los flujos nuevos usar la ruta preferida.
Lea los valores efectivos de su versión antes de cambiar cualquiera de los dos. Bajarlos cierra sesiones que la gente todavía usa. Subirlos hace que el failback parezca no haber ocurrido, porque las conexiones nuevas siguen tomando la ruta antigua durante todo ese tiempo.
Un túnel no renegocia claves porque haya vuelto una ruta
Las asociaciones de seguridad IPsec llevan su propia vida útil negociada y sobreviven al cambio de ruta que las transportaba. Por eso un túnel puede seguir activo durante un failback mientras su direccionamiento exterior ya no coincide con el camino en uso, que es el argumento a favor de DPD y de los diseños que fijan la dirección del peer en lugar de dejarla flotante.
Los diseños con crypto-map y VTI se comportan aquí de forma distinta, y la documentación de Cisco para 9.24 VTI describe la opción basada en rutas. La vieja afirmación general de que una ASA no puede ejecutar VPN basadas en rutas no se sostiene en las versiones admitidas.
Lea las pruebas en este orden
Empiece por el plano de control: show route para la ruta seleccionada, show interface para el estado del enlace y los contadores del monitor SLA del objeto monitorizado. Luego lea show crypto ikev2 sa, o el equivalente de IKEv1, para ver qué peer está vivo, seguido de show crypto ipsec sa para los flujos protegidos. Después reduzca la tabla de conexiones con show conn address <host> y compare la columna de interfaz entre las entradas antiguas y las nuevas. Anote las salidas con marcas de tiempo, porque su orden es el diagnóstico.
Termine con una prueba de aplicación: un flujo que ya existía y otro creado después de que volviera la ruta. Si el flujo antiguo falla y el nuevo funciona, tiene una historia de estado de conexión. Si fallan los dos, el túnel o la política están mal y la tabla de conexiones es una distracción.
Mantenga ese registro con la misma forma en las tres fases y anote la versión exacta. Cuando la línea de tiempo siga apuntando a una sola transición, envíe el registro a soporte en lugar de adivinar un ID de error.