Failback sur l'ASA : ce qui bouge vraiment quand la route revient
Le retour d'une route sur le chemin principal ne signifie pas que les anciens flux ont bougé. Observez ensemble l'uplink, le tunnel, la table de connexions et le résultat applicatif.
Sur une ASA dotée de deux uplinks, le failback n'est pas l'inverse du failover. La route vers le peer change, puis la plateforme doit réconcilier trois machines à états distinctes : la table de routage, les associations de sécurité IKE et IPsec, et la table de connexions. Chacune peut prendre du retard sur les autres, et ce retard est ce que la plupart des gens décrivent comme un tunnel qui ne revient pas.
Ce que le failback change réellement
La recherche de route est la partie visible. Quand l'objet suivi se rétablit, la route surveillée vers l'adresse externe du peer revient, et le paquet suivant que l'ASA envoie reprend le lien principal. Tout ce qui suit dépend de la cohérence entre l'état existant et le nouveau chemin.
ARP et NAT sont les dépendances silencieuses. Un nouveau next hop a besoin d'une passerelle résoluble et d'une traduction qui correspond encore à l'extrémité distante, sinon les premiers paquets après le failback ne vont nulle part et la route paraît correcte alors que rien ne fonctionne.
Quatre vues sur une seule chronologie
Enregistrez les mêmes quatre éléments avant, pendant et après la transition, car un instantané unique ne peut pas dire quelle couche a bougé.
| 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 |
Une route qui n'a jamais changé et une route qui a changé pendant qu'une connexion plus ancienne conservait son état de transfert produisent la même plainte et des preuves totalement différentes.
Pourquoi les anciennes connexions restent sur le chemin de secours
L'ASA ne démonte pas un flux parce qu'une route a changé. Les connexions établies conservent la décision de transfert avec laquelle elles ont été créées, et la plateforme expose des contrôles distincts pour la durée autorisée : floating-connection timeout et connection holddown. le guide des paramètres de connexion de l'ASA 9.24 de Cisco les traite comme deux questions distinctes, et c'est exactement ainsi qu'ils se comportent. L'un régit la survie d'un flux existant, l'autre régit le moment où de nouveaux flux peuvent emprunter le chemin préféré.
Lisez les valeurs effectives de votre version avant de modifier l'une ou l'autre. Les abaisser ferme des sessions que les gens utilisent encore. Les relever donne l'impression que le failback n'a jamais eu lieu, car les nouvelles connexions continuent de prendre l'ancien chemin pendant toute la durée.
Un tunnel ne renégocie pas ses clés parce qu'une route est revenue
Les associations de sécurité IPsec portent leur propre durée de vie négociée et survivent au changement de route qui les a transportées. Un tunnel peut donc rester monté pendant un failback alors que son adressage externe ne correspond plus au chemin utilisé, ce qui plaide pour DPD et pour les conceptions qui épinglent l'adresse du peer au lieu de la laisser flotter.
Les conceptions crypto-map et VTI se comportent ici différemment, et la documentation Cisco pour 9.24 VTI décrit l'option basée sur les routes. La vieille affirmation générale selon laquelle une ASA ne peut pas faire de VPN basés sur les routes ne tient pas pour les versions prises en charge.
Lisez les preuves dans cet ordre
Commencez par le plan de contrôle : show route pour le chemin retenu, show interface pour l'état du lien et les compteurs du moniteur SLA pour l'objet suivi. Lisez ensuite show crypto ikev2 sa, ou l'équivalent IKEv1, pour voir quel peer est actif, puis show crypto ipsec sa pour les flux protégés. Réduisez ensuite la table de connexions avec show conn address <host> et comparez la colonne d'interface entre les entrées anciennes et nouvelles. Notez les sorties avec des horodatages, car leur ordre est le diagnostic.
Terminez par un test applicatif : un flux qui existait déjà et un autre créé après le retour de la route. Si l'ancien flux échoue et que le nouveau fonctionne, vous avez une histoire d'état de connexion. Si les deux échouent, le tunnel ou la politique est en cause et la table de connexions est une distraction.
Conservez ce relevé sous la même forme pendant les trois phases et notez la version exacte. Quand la chronologie pointe toujours vers une seule transition, envoyez le relevé au support plutôt que de deviner un identifiant de bogue.