Failback auf der ASA: Was sich wirklich bewegt, wenn die Route zurückkehrt
Kehrt eine Route auf den primären Pfad zurück, sind alte Flüsse noch nicht umgezogen. Betrachten Sie Uplink, Tunnel, Verbindungstabelle und App-Ergebnis gemeinsam.
Auf einer ASA mit zwei Uplinks ist Failback nicht die Umkehrung von Failover. Die Route zum Peer ändert sich, und danach muss die Plattform drei getrennte Zustandsmaschinen in Einklang bringen: die Routentabelle, die IKE- und IPsec-Sicherheitsassoziationen und die Verbindungstabelle. Jede kann den anderen hinterherlaufen, und genau diese Verzögerung beschreiben die meisten als einen Tunnel, der nicht zurückkommt.
Was Failback tatsächlich ändert
Der Routen-Lookup ist der sichtbare Teil. Erholt sich das überwachte Objekt, kehrt die überwachte Route zur äußeren Adresse des Peers zurück, und das nächste Paket, das die ASA sendet, folgt wieder dem primären Link. Alles danach hängt davon ab, ob der bestehende Zustand mit dem neuen Pfad übereinstimmt.
ARP und NAT sind die stillen Abhängigkeiten. Ein neuer Next Hop braucht ein auflösbares Gateway und eine Übersetzung, die noch zur Gegenseite passt, sonst gehen die ersten Pakete nach dem Failback nirgendwohin, und die Route sieht in Ordnung aus, während nichts funktioniert.
Vier Sichten auf einer Zeitachse
Erfassen Sie dieselben vier Dinge vor, während und nach dem Übergang, denn eine einzelne Momentaufnahme kann nicht sagen, welche Schicht sich bewegt hat.
| 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 |
Eine Route, die sich nie änderte, und eine Route, die sich änderte, während eine ältere Verbindung ihren Weiterleitungszustand behielt, erzeugen dieselbe Beschwerde und völlig unterschiedliche Belege.
Warum alte Verbindungen auf dem Backup-Pfad bleiben
Die ASA baut einen Fluss nicht ab, weil sich eine Route geändert hat. Bestehende Verbindungen behalten die Weiterleitungsentscheidung, mit der sie erstellt wurden, und die Plattform bietet getrennte Steuerungen dafür, wie lange das erlaubt ist: floating-connection timeout und connection holddown. Ciscos Leitfaden zu den Verbindungseinstellungen in ASA 9.24 behandelt sie als verschiedene Fragen, und genau so verhalten sie sich. Die eine regelt das Überleben eines bestehenden Flusses, die andere, wann neue Flüsse den bevorzugten Pfad nutzen dürfen.
Lesen Sie die wirksamen Werte für Ihre Version, bevor Sie eines von beiden ändern. Werden sie gesenkt, schließen Sie Sitzungen, die Leute noch nutzen. Werden sie erhöht, wirkt Failback, als wäre es nie passiert, weil neue Verbindungen die ganze Zeit den alten Pfad nehmen.
Ein Tunnel handelt keine neuen Schlüssel aus, nur weil eine Route zurückkehrt
IPsec-Sicherheitsassoziationen tragen ihre eigene ausgehandelte Lebensdauer und überstehen die Routenänderung, die sie getragen hat. Ein Tunnel kann daher über einen Failback hinweg bestehen bleiben, während seine äußere Adressierung nicht mehr zum genutzten Pfad passt; das ist das Argument für DPD und für Designs, die die Peer-Adresse festnageln, statt sie schweben zu lassen.
Crypto-Map- und VTI-Designs verhalten sich hier anders, und Ciscos Dokumentation zu 9.24 VTI beschreibt die routenbasierte Variante. Die alte pauschale Behauptung, eine ASA könne keine routenbasierten VPNs betreiben, gilt für unterstützte Versionen nicht.
Lesen Sie die Belege in dieser Reihenfolge
Beginnen Sie mit der Control Plane: show route für den gewählten Pfad, show interface für den Link-Zustand und die Zähler des SLA-Monitors für das überwachte Objekt. Lesen Sie dann show crypto ikev2 sa oder das IKEv1-Äquivalent, um zu sehen, welcher Peer lebt, gefolgt von show crypto ipsec sa für die geschützten Flüsse. Verengen Sie danach die Verbindungstabelle mit show conn address <host> und vergleichen Sie die Interface-Spalte bei alten und neuen Einträgen. Schreiben Sie die Ausgaben mit Zeitstempeln auf, denn ihre Reihenfolge ist die Diagnose.
Schließen Sie mit einem Anwendungstest ab: ein Fluss, der bereits existierte, und einer, der nach der Rückkehr der Route entstand. Scheitert der alte Fluss und der neue funktioniert, haben Sie eine Geschichte zum Verbindungszustand. Scheitern beide, sind Tunnel oder Policy falsch, und die Verbindungstabelle ist eine Ablenkung.
Halten Sie diese Aufzeichnung über alle drei Phasen in derselben Form und notieren Sie die genaue Version. Wenn die Zeitachse weiterhin auf einen einzigen Übergang zeigt, senden Sie die Aufzeichnung an den Support, statt eine Bug-ID zu raten.