Unterbrechungsfreier Datenverkehr durch IP SLA und nachverfolgte statische Routenübergänge auf ASA/FTD
Inhalt
Problem
Der Netzwerkverkehr kann sich zeitweise aufhängen oder trennen, oder es kann zu Latenzen kommen, wenn eine ASA/FTD eine statische Route verfolgt hat, da ein IP SLA-Monitor die Überprüfung überspringt und den bevorzugten Pfad vorübergehend als nicht verfügbar markiert.
Umwelt
Beliebige Firepower-Hardware mit ASA oder FTD
Getestete ASA-Softwareversionen: 9.20(4)10 und 9.20(4)34
Mit 'track'-Objekten konfigurierte statische Routen.
IP SLA ICMP-Echotests konfiguriert mit:
Anzahl der Pakete = 3 Tests pro Vorgang.
Frequenz = 5 Sekunden.
Timeout = 5 Sekunden (Standard - nicht vom Benutzer geändert)
Eine Backup-Route, die mit einer größeren administrativen Distanz konfiguriert ist
Anwendungs- oder Netzwerkverkehr über die verfolgte Route
Auflösung
Erhöhte IP SLA-Häufigkeit
Verwenden Sie diese Option, wenn eine Pfadüberwachung und ein automatisches Routen-Failover erforderlich sind.
Konfigurieren Sie die Vorgangshäufigkeit auf einen Wert, der größer als der Vorgangstimeout ist. Beispiel: Behalten Sie das standardmäßige 5-Sekunden-Timeout bei, und erhöhen Sie die Frequenz auf 10 Sekunden:
configure terminal
sla monitor <sla-id>
frequency 10
exit
write memory
Wenden Sie die gleiche Anpassung für alle anderen SLA-Vorgänge mit dem gleichen Zeitraster an.
Anmerkung: Bevor Sie Änderungen vornehmen, stellen Sie sicher, dass das sich ergebende Intervall zur Fehlererkennung die Anforderungen an das Netzwerkdesign erfüllt.
Verifizierung
1. Bestätigen Sie, dass die Route stabil bleibt. Überprüfen Sie, ob die Betriebsfrequenz größer als das Timeout ist.
show route <destination>
2. Bestätigen Sie die IP SLA-Konfiguration:
show sla monitor configuration
3. Überprüfen Sie den Betriebsstatus des IP SLA:
show sla monitor operational-state
Prüfen auf:
Ein Betriebszustand: Aktiver Status.
Kein weiterer Anstieg übersprungener Betriebsabläufe
4. Überprüfen Sie den Track-Status:
show track <track-id>
Die Spur muss aktiv bleiben, solange das überwachte Gateway erreichbar ist.
5. Testen Sie den betroffenen Datenverkehr und die Anwendungen, einschließlich:
Neue Verbindungen.
Bestehende Sitzungen
TCP- und UDP-Datenverkehr (falls zutreffend).
Datenverkehr zu Zielen, die die überwachte Route verwenden.
Anwendungen, die empfindlich auf Routenänderungen oder kurze Unterbrechungen reagieren.
6. Überwachung der Umgebung im Normalbetrieb. Vergewissern Sie sich, dass sich die bevorzugte Route nicht wiederholt zurückzieht und wieder auftaucht.
Wenn das Problem erneut auftritt, sammeln Sie diese Daten, während das Problem aktiv ist:
show sla monitor configuration
show sla monitor operational-state
show track
show route
show asp drop
show tech-support
Sammeln Sie außerdem Paketerfassungen für die IP SLA-Tests und den betroffenen Datenverkehr.
Ursache
Die IP SLA-Betriebshäufigkeit und das Timeout wurden beide für fünf Sekunden konfiguriert. Unter bestimmten Bedingungen betrachtete der IP SLA-Planer den vorherigen Vorgang als aktiv, als der nächste Vorgang geplant wurde.
Belege enthalten:
Eine hohe Anzahl übersprungener IP SLA-Vorgänge.
Paketerfassungen zeigen erfolgreiche Testantworten an, jedoch ca. 10 Sekunden Lücken zwischen den Testgruppen anstelle des konfigurierten Intervalls von 5 Sekunden.
Es gibt keine Hinweise auf eine Überlastung der Schnittstelle, das Verwerfen des Schnittstellenpuffers oder die Erschöpfung der Appliance-Ressourcen.
Routenänderungen, die auftreten, wenn das Track-Objekt zwischen Nach oben und Nach unten wechselt.
Beim Übergang des bevorzugten Streckenobjekts nach Down wurde die zugehörige statische Route zurückgezogen, und der Verkehr wurde auf die Route mit höherer Entfernung verlagert. Als die Spur wieder nach Up zurückkehrte, wurde die bevorzugte Route neu installiert. Diese Routenänderungen führten zu Unterbrechungen des aktiven Datenverkehrs und können zu Anwendungszeitüberschreitungen, Latenzen, Unterbrechungen oder Verbindungsunterbrechungen führen.
Das Problem setzte sich nach der Wiederherstellung der ASA-Software fort, sodass die verfügbaren Daten keine softwareversionsspezifische Regression aufwiesen.
Verwandte Inhalte
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
10-Nov-2026
|
Erstveröffentlichung |
Feedback