%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.
Für dieses Dokument bestehen keine speziellen Anforderungen.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
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.
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 |
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.
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:
Das Paket wird in der Ausgabewarteschlange der Tunnelschnittstelle in die Warteschlange gestellt.
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.
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.
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
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.
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.
Konfigurieren Sie den Befehl tunnel key auf dem Schnittstellentunnel 10 auf beiden Routern. Dieser Befehl aktiviert Multicast auf GRE.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
11-Sep-2018 |
Erstveröffentlichung |