Fehlerbehebung bei IGP-Flaps, Paketverlust oder Tunnel-Bounce über einen VPN-Tunnel mit EEM und IP SLAs

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)

• Tunnel-IP-Adresse zu Tunnel-IP-Adresse (10.1.12.100 > 10.1.12.1)

  ip sla 200
      icmp-echo 10.1.12.1 source-interface Tunnel100
      frequency 5
  ip sla schedule 200 life forever start-time now

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

• Underground-Objekt für Verbindungsspuren
  

  track 100 ip sla 100
     delay down 15 up 15

• Overlay-Verbindungsspurobjekt
  

  track 200 ip sla 200
     delay down 15 up 15

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:

1. Beide SLAs schlagen fehl. Das bedeutet:
   1. Die Layer-3-Anbindung zwischen den beiden Peers über das Underlay (Internet/MPLS) wurde unterbrochen. Dies bedarf weiterer Untersuchungen.
   2. Es besteht kein Problem mit dem Tunnel. Es ist gescheitert, weil es Opfer der Unterbrechung des Unterlags ist.
2. Das physische SLA schlägt nicht fehl, das Tunnel-SLA jedoch nicht. Das bedeutet:
   1. Die Layer-3-Verbindung zwischen den beiden Peers im Internet funktioniert ordnungsgemäß.
   2. Es besteht ein Problem mit dem Tunnel. Eine weitere Untersuchung des Tunnels ist erforderlich.
3. Keiner der SLAs schlägt fehl. Das bedeutet:
   1. Die Layer-3-Verbindung zwischen den beiden Peers im Internet funktioniert ordnungsgemäß.
   2. Die Layer-3-Unicast-Anbindung zwischen den beiden Peers im Tunnel funktioniert ordnungsgemäß.
   3. Die Layer-3-Multicast-Konnektivität über den Tunnel ist unbekannt. Um dies zu testen, pingen Sie die vom IGP verwendete Multicast-Adresse.
   4. Wenn der Test funktioniert, weist dies auf ein Anwendungsproblem hin (EIGRP/OSFP/BGP). Weitere Protokolluntersuchungen sind erforderlich.