Einleitung
In diesem Dokument werden die Schritte beschrieben, die bei EIGRP/OSPF/BGP-Flaps über einen DMVPN/GRE/sVTI/FlexVPN-Tunnel unternommen werden.
Hintergrundinformationen
Um dieses Problem zu beheben, muss zunächst die Frage "Handelt es sich um ein VPN-, Routing-Protokoll- oder ISP-Problem?" beantwortet werden. Um die Frage zu beantworten, müssen während der Flapping/Ausfallzeit Verbindungstests im gesamten Underlay (normalerweise im Internet oder einem privaten WAN) und Overlay (in der Regel im VPN-Tunnel) durchgeführt werden. Leider können diese Flapping-Ereignisse vorübergehend und zeitweilig auftreten. Daher kann es schwierig sein, diese Tests während der Problemzeit durchzuführen. Dieses Dokument enthält Anleitungen zur Verwendung des IP Service Level Agreement (SLA), zur Verfolgung von Objekten und des Embedded Event Manager (EEM), um diese Informationen zum Zeitpunkt des Problems automatisch zu erfassen.
Informationen zu Funktionen
IP SLAs sind Prozesse, die im Hintergrund auf dem Router ausgeführt werden und eine Reihe von Netzwerkbedingungen testen. In diesem Dokument wird die allgemeine IP-Konnektivität mit dem "icmp-echo"
testen.
Ein Track-Objekt kann dann den Status des IP SLA verfolgen. Mit einem EEM-Applet kann dann der Netzwerkstatus im Syslog-Puffer aufgezeichnet werden, wenn sich das Verfolgungsobjekt ändert.
Verwenden Sie den im Syslogs-Verlauf aufgezeichneten Netzwerkstatus, um den Zustand des Netzwerks während der Flapping/Ausfallzeit zu ermitteln und festzustellen, ob ein Problem mit dem Verschlüsselungs-, Transport- oder IGP-System (Interior Gateway Protocol) aufgetreten ist.
Methodik
Schritt 1: Definition eines SLA zur Verfolgung des Underlay (Internetverbindung)
- Option A
Öffentliche IP-Adresse an öffentliche IP-Adresse (172.18.3.52 > 172.20.5.43). Da der Remote-Peer normalerweise auf ICMP antwortet, muss dieses SLA nur auf einem Gerät definiert werden.
ip sla 100
icmp-echo 172.20.5.43 source-interface FastEthernet4
frequency 5
ip sla schedule 100 life forever start-time now
- Option B
Anmerkung: In einigen Umgebungen werden ICMP-Pakete (Internet Control Message Protocol) im Underlay-/Transportnetzwerk blockiert. In diesen Umgebungen udp-echo
anstelle von icmp-echo
für IP SLA.
IP SLA-Initiator (linker Router)
ip sla 100
udp-echo 172.20.5.43 1501 source-ip 172.18.3.52 source-port 1501 control disable
frequency 5
ip sla schedule 100 life forever start-time now
IP SLA-Responder (rechter Router)
ip sla responder
ip sla responder udp-echo ipaddress 172.20.5.43 port 1501
Schritt 2: Definition eines SLA zur Verfolgung des Overlays (Tunnelanbindung)
Diese SLAs senden alle fünf Sekunden ein einzelnes Paket an die definierten Peers. Wenn der Peer antwortet, wird das SLA mit "OK
". Wenn sie nicht antwortet, wird sie mit "Timeout
". Die Track-Objekte überwachen den Status des SLA.
Schritt 3: Definition von Verfolgungsobjekten zur Überwachung von SLA-Zuständen
Wenn sich das Track-Objekt ändert, kann eine Nachricht in die Syslogs eingefügt werden.
Schritt 4: Definieren eines EEM-Applets zum Aufzeichnen, wenn sich Track-Objekte ändern
- Erstellen Sie ein EEM-Applet für den Fall, dass der Underlay-Transport ausfällt, und ein anderes für den Fall, dass es sich wiederherstellt.
event manager applet ipsla100down
event track 100 state down
action 1.0 syslog msg "Underlay SLA probe failed!"
event manager applet ipsla100up
event track 100 state up
action 1.0 syslog msg "Underlay SLA probe came up!"
- Erstellen Sie ein EEM-Applet für den Fall, dass der Overlay-Transport ausfällt, und ein anderes für den Fall, dass es wiederhergestellt wird.
event manager applet ipsla200down
event track 200 state down
action 1.0 syslog msg "Overlay SLA probe failed!"
event manager applet ipsla200up
event track 200 state up
action 1.0 syslog msg "Overlay SLA probe came up!"
Datenanalyse
Wenn ein Ausfall auftritt, erfassen Sie die Ausgabe der show log
aus. Suchen Sie die im vorherigen Abschnitt gezeigten SLA-Meldungen.
Es gibt drei mögliche Szenarien:
- Beide SLAs schlagen fehl. Das bedeutet:
- Die Layer-3-Anbindung zwischen den beiden Peers über das Underlay (Internet/MPLS) wurde unterbrochen. Dies bedarf weiterer Untersuchungen.
- Es besteht kein Problem mit dem Tunnel. Es ist gescheitert, weil es Opfer der Unterbrechung des Unterlags ist.
- Das physische SLA schlägt nicht fehl, das Tunnel-SLA jedoch nicht. Das bedeutet:
- Die Layer-3-Verbindung zwischen den beiden Peers im Internet funktioniert ordnungsgemäß.
- Es besteht ein Problem mit dem Tunnel. Eine weitere Untersuchung des Tunnels ist erforderlich.
- Keiner der SLAs schlägt fehl. Das bedeutet:
- Die Layer-3-Verbindung zwischen den beiden Peers im Internet funktioniert ordnungsgemäß.
- Die Layer-3-Unicast-Anbindung zwischen den beiden Peers im Tunnel funktioniert ordnungsgemäß.
- Die Layer-3-Multicast-Konnektivität über den Tunnel ist unbekannt. Um dies zu testen, pingen Sie die vom IGP verwendete Multicast-Adresse.
- Wenn der Test funktioniert, weist dies auf ein Anwendungsproblem hin (EIGRP/OSFP/BGP). Weitere Protokolluntersuchungen sind erforderlich.