Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Netzwerkdiagramm

Konfigurationen

Beobachtung

Fehlerbehebung

Lösung

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

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

Lösung

Zugehörige Informationen

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.

Konfigurationen

- R1

- R3

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

- Warum kann ich nicht im Internet surfen, wenn ich einen GRE-Tunnel verwende?

- Unterstützung der EIGRP-Technologie (Interior Gateway Routing Protocol)