UDP-Datenverkehr über ASA fällt aus, nachdem der primäre ISP-Link in einer Konfiguration mit zwei ISPs wieder online ist

Einleitung

Wenn eine Adaptive Security Appliance (ASA) über zwei Ausgangsschnittstellen pro Ziel-Subnetz verfügt und die bevorzugte Route zu einem Ziel für einige Zeit aus der Routing-Tabelle entfernt wird, können UDP-Verbindungen (User Datagram Protocol) fehlschlagen, wenn die bevorzugte Route der Routing-Tabelle erneut hinzugefügt wird. TCP-Verbindungen können ebenfalls von dem Problem betroffen sein. Da TCP jedoch Paketverluste erkennt, werden diese Verbindungen von den Endpunkten automatisch abgebrochen und mithilfe der optimalen Routen neu erstellt, nachdem die Routen geändert wurden.

Dieses Problem tritt auch dann auf, wenn ein Routing-Protokoll verwendet wird und eine Topologieänderung eine Änderung der Routing-Tabelle auf der ASA auslöst.

Vorbereitungen

Anforderungen

Um dieses Problem zu beheben, muss sich die Routing-Tabelle der ASA ändern. Dies ist bei redundanten dualen ISP-Verbindungen üblich, oder wenn die ASA Routen über ein IGP (OSPF, EIGRP, RIP) lernt.

Dieses Problem tritt auf, wenn die primäre ISP-Verbindung wieder online geht oder das IGP eine Rekonvergenz erkennt, aufgrund derer eine weniger bevorzugte Route, die von der ASA verwendet wurde, durch die bevorzugte Route mit niedrigeren Metriken ersetzt wird. In diesem Fall würden langlebige Verbindungen wie UDP SIP-Registrierungen, GRE usw. fehlschlagen, sobald die primäre oder bevorzugte Route in der Routing-Tabelle der ASA neu installiert wird.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Hardware- und Software-Versionen:

• Alle Cisco Adaptive Security Appliances der Serie ASA 5500

• ASA-Versionen 8.2(5), 8.3(2)12, 8.4(1)1, 8.5(1) und höher

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den technischen Tipps von Cisco zu Konventionen.

Problem

Wenn ein Routing-Tabelleneintrag aus der Routing-Tabelle der ASA entfernt wird und es keine Routen aus einer Schnittstelle zum Erreichen eines Ziels gibt, werden Verbindungen, die durch die Firewall mit diesem fremden Ziel erstellt wurden, von der ASA gelöscht. Dies geschieht, sodass die Verbindungen über eine andere Schnittstelle mit Routingeinträgen für das vorhandene Ziel wieder aufgebaut werden können.

Wenn der Tabelle jedoch spezifischere Routen hinzugefügt werden, werden die Verbindungen nicht aktualisiert, um die neuen spezifischeren Routen zu verwenden, und es wird weiterhin die weniger optimale Schnittstelle verwendet.

Bedenken Sie beispielsweise, dass die Firewall über zwei Schnittstellen zum Internet verfügt - "Außen" und "Backup" - und dass diese beiden Routen in der Konfiguration der ASA vorhanden sind:

route outside 0.0.0.0 0.0.0.0 10.1.1.1 1 track 1
route backup 0.0.0.0 0.0.0.0 172.16.1.1 254

Wenn sowohl die Außen- als auch die Backup-Schnittstelle "up" sind, verwenden ausgehende Verbindungen, die über die Firewall erstellt werden, die externe Schnittstelle, wie sie die bevorzugte Metrik 1 aufweist. Wenn die externe Schnittstelle ausgeschaltet wird (oder die SLA-Überwachungsfunktion, die die Route verfolgt, einen Verbindungsverlust mit der verfolgten IP feststellt), werden Verbindungen, die die externe Schnittstelle verwenden, über die Backup-Schnittstelle ausgeschaltet und neu erstellt, da die Backup-Schnittstelle die einzige Schnittstelle mit einer Route zur Ziel.

Das Problem tritt auf, wenn die externe Schnittstelle wieder aktiviert wird oder die verfolgte Route wieder die bevorzugte Route wird. Die Routing-Tabelle wird aktualisiert, um die ursprüngliche Route vorzuziehen. Bestehende Verbindungen bestehen jedoch weiterhin auf der ASA und durchlaufen die Backup-Schnittstelle. Sie werden NICHT gelöscht und auf der externen Schnittstelle mit der stärker bevorzugten Metrik neu erstellt. Dies liegt daran, dass die Backup-Standardroute immer noch in der schnittstellenspezifischen Routing-Tabelle der ASA vorhanden ist. Die Verbindung verwendet weiterhin die Schnittstelle mit der weniger bevorzugten Route, bis die Verbindung gelöscht wird. im Fall von UDP auf unbestimmte Zeit.

Diese Situation kann zu Problemen mit langlebigen Verbindungen führen, wie z. B. externen SIP-Registrierungen oder anderen UDP-Verbindungen.

Lösung

Um dieses spezifische Problem zu beheben, wurde der ASA eine neue Funktion hinzugefügt, die dazu führt, dass Verbindungen abgebrochen und auf einer neuen Schnittstelle neu erstellt werden, wenn der Routing-Tabelle eine bevorzugtere Route zum Ziel hinzugefügt wird. Um die Funktion zu aktivieren (sie ist standardmäßig deaktiviert), legen Sie einen Timeout ungleich null auf den Befehl timeout floating-conn fest. Diese Zeitüberschreitung (angegeben in HH:MM:SS) gibt die Zeit an, die die ASA wartet, bevor sie die Verbindung abbricht, sobald eine weitere bevorzugte Route zur Routing-Tabelle hinzugefügt wird:

Dies ist ein Beispiel für die Aktivierung der Funktion über die Kommandozeile. Wenn mit dieser CLI ein Paket auf einer vorhandenen Verbindung empfangen wird, für die es jetzt eine andere, bevorzugtere Route zum Ziel gibt, wird die Verbindung 1 Minute später beendet (und mithilfe der neuen, bevorzugteren Route neu erstellt):

ASA# config terminal
ASA(config)# timeout floating-conn 0:01:00
ASA(config)# end
ASA# show run timeout
timeout conn 1:00:00 half-closed 0:10:00 udp 0:50:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:01:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout xlate 0:01:00
timeout pat-xlate 0:00:30
timeout floating-conn 0:01:00
ASA#

Diese Funktion wird der ASA-Plattform in den Versionen 8.2(5), 8.3(2)12, 8.4(1)1 und 8.5(1) hinzugefügt, einschließlich neuerer Versionen der ASA-Software.

Wenn Sie eine Version von ASA-Code ausführen, die diese Funktion nicht implementiert, können Sie das Problem umgehen, indem Sie die UDP-Verbindungen, die weiterhin die weniger bevorzugte Route verwenden, manuell leeren, obwohl eine bessere Route über einen eindeutigen lokalen Host <IP> oder Clear-Conn<IP> bereitgestellt wird.

Die Befehlsreferenz listet diese neue Funktion im Abschnitt Timeout auf.

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme