Die Fehlermeldung "%TUN-5-RECURDOWN" und Flapping von EIGRP/OSPF/BGP-Nachbarn über einen GRE-Tunnel

Download-Optionen

  • PDF     (209.6 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (97.9 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (111.6 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:11. September 2018
Dokument-ID:22327

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

%TUN-5-RECURDOWN: Tunnel0 ist aufgrund einer rekursiven Routing-Fehlermeldung vorübergehend deaktiviert, sodass der GRE-Tunnel-Router (Generic Routing Encapsulation) ein rekursives Routing-Problem festgestellt hat. Diese Erkrankung ist in der Regel auf eine der folgenden Ursachen zurückzuführen:

  • Eine Fehlkonfiguration, die den Router dazu veranlasst, mithilfe der Tunnelschnittstelle selbst eine Route zur Tunnelzieladresse durchzuführen (rekursives Routing).

  • Eine temporäre Instabilität, die durch das Flapping von Routen an anderen Stellen im Netzwerk verursacht wird

Der Tunnelschnittstellenstatus hängt von der IP-Erreichbarkeit zum Tunnelziel ab. Wenn der Router einen rekursiven Routing-Fehler für das Tunnelziel erkennt, wird die Tunnelschnittstelle einige Minuten lang heruntergefahren, sodass sich die Situation, die das Problem verursacht, bei der Konvergenz der Routing-Protokolle lösen kann. Wenn das Problem durch Fehlkonfiguration verursacht wird, kann die Verbindung unbegrenzt oszillieren.

Ein weiteres Symptom dieses Problems ist die kontinuierliche Flapping von Nachbarn wie EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First) oder Border Gateway Protocol (BGP), wenn sich die Nachbarn über einem GRE-Tunnel befinden.

Dieses Dokument zeigt ein Beispiel für die Fehlerbehebung bei einer oszillierenden Tunnelschnittstelle, auf der EIGRP ausgeführt wird.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- oder Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Netzwerkdiagramm

Router 1 (R1) und Router 3 (R3) sind mit Router 2 (R2) verbunden. Die Netzwerkverbindung ist so aufgebaut, dass R1 die Loopback-Schnittstelle von R3 über R2 und umgekehrt erreichen kann. EIGRP wird über die Tunnelschnittstelle auf R1 und R3 ausgeführt. R2 ist nicht Teil der EIGRP-Domäne.

gre_flap_01.gif

Konfigurationen

R1 
hostname R1
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.3.3.3
!
interface Serial0
 ip address 172.16.15.1 255.255.255.0
 encapsulation ppp
!
router eigrp 1
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.15.2

R3 
hostname R3
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.3 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.1.1.1
!
interface Serial1
 ip address 172.16.25.3 255.255.255.0
!
router eigrp 1
 network 10.3.3.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.25.2

Beobachtung

Beobachten Sie diese Fehlermeldungen bei R1 und R3. Der Zustand der Tunnelschnittstelle schwankt kontinuierlich zwischen oben und unten.

01:11:39: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:11:48: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:11:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down
01:12:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:12:58: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:12:59: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down

Hinweis: Jede mit einem Zeitstempel versehene Zeile mit vorangestelltem Beispiel wird in der tatsächlichen Ausgabe auf einer Zeile angezeigt.

Fehlerbehebung

Dies ist die Route zum Tunnelziel 10.3.3.3 auf R1, bevor die Tunnelschnittstelle hochgefahren wird:

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Loopback0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

Das Tunnelziel 10.3.3.3 führt die Standardroute über 172.16.15.2 (Serial 0) aus.

Beachten Sie jetzt die Routing-Tabelle nach dem Hochfahren der Tunnelschnittstelle, wie hier gezeigt:

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:00:00, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 2 subnets
D       10.3.3.0 [90/297372416] via 192.168.1.3, 00:00:00, Tunnel0
C       10.1.1.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

Die Route zum Tunnelziel 10.3.3.3 wird über EIGRP erlernt, und der nächste Hop ist Schnittstellentunnel 0.

In dieser Situation ist der beste Pfad zum Tunnelziel die Tunnelschnittstelle. Dies geschieht jedoch:

  1. Das Paket wird in der Ausgabewarteschlange der Tunnelschnittstelle in die Warteschlange gestellt.

  2. Die Tunnelschnittstelle fügt dem Paket einen GRE-Header hinzu und ordnet das Paket in die Warteschlange für das Transportprotokoll ein, das zur Zieladresse der Tunnelschnittstelle bestimmt ist.

  3. IP sucht die Route zur Zieladresse und erfährt, dass sie über die Tunnelschnittstelle verläuft, die das Paket an Schritt 1 zurückgibt. Daher ist eine rekursive Routing-Schleife vorhanden.

Lösung

Konfigurieren Sie statische Routen für das Tunnelziel sowohl auf R1 als auch auf R3.

R1(config)# ip route 10.3.3.3 255.255.255.255  serial 0
R3(config)# ip route 10.1.1.1 255.255.255.255 serial 1

Nun beobachten Sie die IP-Route auf R1, wie unten gezeigt.

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:01:08, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.3.3.3/32 is directly connected, Serial0
D       10.3.3.0/24 [90/297372416] via 192.168.1.3, 00:01:08, Tunnel0
C       10.1.1.0/24 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

Eine spezifischere statische Route (10.3.3.3/32) ist der weniger spezifischen EIGRP-bezogenen Route (10.3.3.0/24) für das Tunnelziel vorzuziehen. Diese spezifischere statische Route vermeidet die rekursive Routing-Schleife, die Flapping-Tunnelschnittstelle und damit das Flapping von EIGRP-Nachbarn.

R1# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 192.168.1.1/24
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec)
  Tunnel source 10.1.1.1 (Loopback0), destination 10.3.3.3

%Warnung: Funktion wird in der Hardware nicht unterstützt. Tunnelpakete werden per Software-Switching übertragen.

Die Meldung wird angezeigt, wenn der gleiche Loopback oder die gleiche physische Adresse als Quelle für zwei verschiedene Tunnel verwendet wird. Aus diesem Grund wird jedes Paket an den Prozessor weitergeleitet, anstatt Hardware-Switches zu verwenden.

Dieses Problem kann behoben werden, wenn Sie sekundäre Adressen auf einer Loopback-Schnittstelle verwenden oder wenn Sie mehrere Loopback-Schnittstellen für die Tunnelquellenadressen verwenden.

Das OSPF-Hello-Paket wird von einem Router über den GRE-Tunnel gesendet, kommt jedoch nicht am anderen Ende des Tunnels an.

In einem OSPF-aktivierten Netzwerk sendet der Router R1 das OSPF-Hello-Paket über den GRE-Tunnel, wird aber nicht vom Router R3 empfangen. Verwenden Sie den Befehl debug ip ospf hello, um die Hello-Ereignisse zu debuggen. 

R1#debug ip ospf hello
May 31 13:58:29.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:39.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:49.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1


R3#debug ip ospf hello
May 31 15:02:07 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3
May 31 15:02:09 ADT: OSPF: Rcv hello from 172.16.15.1 area 0.0.0.12 from Tunnel0 192.168.1.1
May 31 15:02:09 ADT: OSPF: Send immediate hello to nbr 172.16.15.3, src address 192.168.1.3, on Tunnel0
May 31 15:02:09 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3

!--- The previous output shows that the hello packets !--- re sent by R1 but not received by R3.

Lösung

Konfigurieren Sie den Befehl tunnel key auf dem Schnittstellentunnel 10 auf beiden Routern. Dieser Befehl aktiviert Multicast auf GRE.

Zugehörige Informationen

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
11-Sep-2018
Erstveröffentlichung

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren