Bestimmen der Auswirkungen auf die GRE-Tunnelschnittstellenstatus
Inhalt
Einleitung
In diesem Dokument werden die verschiedenen Bedingungen beschrieben, die den Status einer GRE-Tunnel-Schnittstelle (Generic Routing Encapsulation) beeinflussen können.
Hintergrundinformationen
GRE-Tunnel sind vollständig stateless. Das bedeutet, dass jeder Tunnelendpunkt keine Informationen über den Status oder die Verfügbarkeit des entfernten Tunnelendpunkts speichert.
Dies hat zur Folge, dass der lokale Tunnel-Endpunkt-Router standardmäßig das Leitungsprotokoll der GRE-Tunnelschnittstelle nicht deaktivieren kann, wenn das Remote-Ende des Tunnels nicht erreichbar ist.
Die Möglichkeit, eine Schnittstelle (in diesem Fall) als ausgefallen zu markieren, wird verwendet, um alle statischen Routen in der Routing-Tabelle zu entfernen, die diese Schnittstelle als ausgehende Schnittstelle verwenden.
Wenn das Leitungsprotokoll für eine Schnittstelle in "Down" (Heruntergefahren) geändert wird, werden alle statischen Routen, die diese Schnittstelle anzeigen, aus der Routing-Tabelle entfernt.
Dies ermöglicht die Installation einer alternativen (schwebenden) statischen Route oder eines richtlinienbasierten Routing (Policy Based Routing, PBR), um einen alternativen Next-Hop oder eine alternative Schnittstelle auszuwählen.
Darüber hinaus gibt es andere Anwendungen, die ausgelöst werden, wenn sich der Zustand einer Schnittstelle ändert. Beispiel: 'backup interface <b-interface>'.
Vier verschiedene Tunnelzustände
Es gibt vier mögliche Zustände, in denen eine GRE-Tunnelschnittstelle vorhanden ist:
- Up/up (Hochgefahren/Hochgefahren) - Dies impliziert, dass der Tunnel voll funktionsfähig ist und den Datenverkehr weiterleitet. Sie ist sowohl administrativ als auch protokollarisch in Ordnung.
- Administrative Aus-/Herunterfahren - Dies impliziert, dass die Schnittstelle vom Administrator heruntergefahren wurde.
- Up/Down - Dies impliziert, dass, obwohl der Tunnel administrativ aktiv ist, etwas dazu führt, dass das Leitungsprotokoll auf der Schnittstelle ausgefallen ist.
- Reset/Down - Dies ist normalerweise ein vorübergehender Zustand, wenn der Tunnel durch Software zurückgesetzt wird. Dies geschieht in der Regel, wenn der Tunnel mit einem Next Hop Server (NHS) falsch konfiguriert ist, der seine eigene IP-Adresse hat.
Wenn eine Tunnelschnittstelle zum ersten Mal erstellt wird und keine andere Konfiguration darauf angewendet wird, wird die Schnittstelle nicht standardmäßig geschlossen:
Router#show run interface tunnel 1
Building configuration...
Current configuration : 40 bytes
!
interface Tunnel1
no ip address
end
In diesem Zustand ist die Schnittstelle immer aktiv/inaktiv:
Router(config-if)#do show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 172.16.52.1 YES NVRAM administratively down down
GigabitEthernet0/1 10.36.128.49 YES NVRAM down down
GigabitEthernet0/2 unassigned YES NVRAM down down
GigabitEthernet0/3 unassigned YES NVRAM down down
Loopback1 192.168.2.1 YES NVRAM up up
Tunnel1 unassigned YES unset up down
Dies liegt daran, dass die Schnittstelle administrativ aktiviert ist, das Leitungsprotokoll jedoch ausgefallen ist, da sie weder eine Tunnelquelle noch ein Tunnelziel aufweist.
Damit diese Schnittstelle aktiviert bzw. aktiviert wird, muss eine gültige Tunnelquelle und ein gültiges Tunnelziel konfiguriert werden:
Router#show run interface tunnel 1
Building configuration...
Current configuration : 113 bytes
!
interface Tunnel1
ip address 10.1.1.1 255.255.255.0
tunnel source Loopback1
tunnel destination 10.0.0.1
end
Router#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 172.16.52.1 YES NVRAM up up
GigabitEthernet0/1 10.36.128.49 YES NVRAM down down
GigabitEthernet0/2 unassigned YES NVRAM down down
GigabitEthernet0/3 unassigned YES NVRAM down down
Loopback0 unassigned YES unset up up
Loopback1 192.168.2.1 YES manual up up
Tunnel1 10.1.1.1 YES manual up up
Die vorige Sequenz zeigt Folgendes:
- Eine gültige Tunnelquelle besteht aus einer Schnittstelle, die sich selbst im eingeschalteten Zustand befindet und für die eine IP-Adresse konfiguriert ist.
- Wenn beispielsweise die Tunnelquelle in Loopback0 geändert wurde, würde die Tunnelschnittstelle ausfallen, obwohl Loopback0 im Status "up/up" ist:
Router(config)#interface tunnel 1
Router(config-if)#tunnel source loopback 0
Router(config-if)#
*Sep 6 19:51:31.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down - Ein gültiges Tunnelziel kann geroutet werden. Sie muss jedoch nicht erreichbar sein, wie aus diesem Ping-Test hervorgeht:
Router#show ip route 10.0.0.1
% Network not in table
Router#show ip route | inc 0.0.0.0
Gateway of last resort is 172.16.52.100 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 172.16.52.100
Router#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Bisher wurde der Tunnel als Point-to-Point (P2P) GRE-Tunnel konfiguriert, was der Standard ist.
Wenn dieser Tunnel in einen mGRE-Tunnel (Multipoint GRE) umgewandelt werden sollte, ist für den Zustand "up" lediglich eine gültige Tunnelquelle erforderlich.
Anmerkung: Ein mGRE-Tunnel kann viele Tunnelziele haben, sodass dieser nicht zur Steuerung des Tunnelschnittstellenstatus verwendet werden kann.
Router#show run interface tunnel 1
Building configuration...
Current configuration : 129 bytes
!
interface Tunnel1
ip address 10.1.1.1 255.255.255.0
no ip redirects
tunnel source Loopback1
tunnel mode gre multipoint
end
Router#show ip interface brief | include Tunnel
Tunnel1 10.1.1.1 YES manual up up
Wenn die Tunnelschnittstelle vom Administrator deaktiviert wurde, wechselt der Tunnel sofort in den administrativen Aus-/Aus-Zustand:
Router#show run interface tunnel 1
Building configuration...
Current configuration : 50 bytes
!
interface Tunnel1
no ip address
shutdown
end
Router#show ip interface brief | include Tunnel
Tunnel1 unassigned YES unset administratively down down
P2P GRE-Tunnelstatus
Eine P2P GRE-Tunnelschnittstelle wird in der Regel aktiviert, sobald sie mit einer gültigen Tunnelquellenadresse oder Schnittstelle konfiguriert ist, die aktiv ist, und einer Tunnelziel-IP-Adresse, die routbar ist (siehe weiter oben).
Leitungsprotokoll lokal auf dem Router heruntergefahren
Unter normalen Umständen gibt es nur drei Gründe, warum ein GRE-Tunnel im Hoch-/Herunterzustand ist:
- Es gibt keine Route (einschließlich der Standardroute) zur Tunnel-Zieladresse.
- Die Schnittstelle, die die Tunnelquelle verankert, ist ausgefallen.
- Die Route zur Tunnel-Zieladresse verläuft durch den Tunnel selbst, was zu einer Rekursion führt.
Diese drei Regeln (missing, Route, Interface Down und fehlgeleitetes Tunnelziel) stellen für den Router an den Tunnelendpunkten lokale Probleme dar.
Sie behandeln weder Probleme im dazwischen liegenden Netzwerk noch andere Funktionen im Zusammenhang mit dem GRE-Tunnel, die konfiguriert werden können. In diesem Dokument werden Szenarien beschrieben, in denen andere Faktoren den Zustand des GRE-Tunnels beeinflussen können.
GRE-Tunnel-Keepalive
Die Grundregeln gelten nicht für den Fall, dass GRE-getunnelte Pakete erfolgreich weitergeleitet werden, aber verloren gehen, bevor sie das andere Ende des Tunnels erreichen.
Dies führt dazu, dass Datenpakete, die den GRE-Tunnel durchlaufen, verloren gehen, obwohl potenziell eine alternative Route verfügbar ist, die PBR verwendet, oder eine statische Floating-Route über eine andere Schnittstelle.
Keepalives an der GRE-Tunnelschnittstelle werden verwendet, um dieses Problem auf die gleiche Weise zu lösen wie Keepalives an physischen Schnittstellen.
Mit Cisco IOS® Software Release 12.2(8)T ist es möglich, Keepalives auf einer P2P GRE-Tunnelschnittstelle zu konfigurieren. Mit dieser Änderung wird die Tunnelschnittstelle dynamisch heruntergefahren, wenn die Keepalives für eine bestimmte Zeit fehlschlagen.
Weitere Informationen zur Funktionsweise von GRE-Tunnelkeepalives finden Sie unter GRE Tunnel Keepalives.
GRE-Tunnel mit Tunnelschutz
In den Cisco IOS® Softwareversionen 15.4(3)M/15.4(3)S und höher entspricht der Protokollstatus der GRE-Tunnelverbindung dem Status der IPsec Security Association (SA). Daher kann das Leitungsprotokoll inaktiv bleiben, bis die IPsec-Sitzung vollständig eingerichtet ist.
Dies wurde mit der Cisco Bug-ID CSCum34057 bestätigt (erster Versuch mit der Cisco Bug-ID CSCuj29996 und anschließend mit der Cisco Bug-ID CSCuj9287).
mGRE-Tunnelschnittstellen (Multipoint GRE)
Für mGRE-Tunnelschnittstellen sind einige der vorherigen Prüfungen für P2P-Tunnel nicht anwendbar (da es kein festes Tunnelziel gibt).
Die Gründe, warum ein mGRE-Tunnelleitungsprotokoll ausgefallen sein kann, sind wie folgt:
- Die Tunnelquellenschnittstelle ist ausgefallen.
- Wenn die Schnittstellenzustandssteuerung für Dynamic Multipoint VPN (DMVPN) aktiviert ist und kein NHS antwortet, wird das Leitungsprotokoll deaktiviert.
- Weitere Informationen zur Schnittstellenzustandskontrolle finden Sie im Konfigurationsleitfaden für die DMVPN-Tunnelzustandsüberwachung und -wiederherstellung.
Abhängigkeiten vom Redundanzstatus
Wenn eine Tunnel-Quell-IP-Adresse als Redundanz-IP-Adresse konfiguriert ist (z. B. eine Hot Standby Router Protocol Virtual IP (HSRP VIP)-Adresse), verfolgt der Tunnel-Schnittstellenstatus den Redundanzstatus nach.
Dadurch wird eine weitere Überprüfung hinzugefügt, die solche Tunnelschnittstellen im Leitungsprotokoll-Down-Zustand belässt, bis der Redundanzstatus zu ACTIVE wechselt.
In diesem Beispiel führt eine falsch konfigurierte IP-Zone-Standardkonfiguration dazu, dass sich die Redundanz im VERHANDLUNGS-Zustand befindet, und hält solche Tunnelschnittstellen im ausgefallenen Zustand:
Router#show redundancy state
my state = 3 -NEGOTIATION
peer state = 1 -DISABLED
Mode = Simplex
Unit ID = 0
Maintenance Mode = Disabled
Manual Swact = disabled (system is simplex (no peer unit))
Communications = Down Reason: Simplex mode
client count = 16
client_notification_TMR = 60000 milliseconds
RF debug mask = 0x0
Router#show interface tunnel100
Tunnel100 is up, line protocol is down
Hardware is Tunnel
Internet address is 172.16.1.100/24
MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.122.162.254 (GigabitEthernet0/1)
Tunnel Subblocks:
src-track:
Tunnel100 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 2 members (includes
iterators), on interface <OK>
Tunnel protocol/transport multi-GRE/IP
<SNIP>
Fehlerbehebung
Zusätzlich zu den oben genannten Gründen kann die Auswertung des Tunnellinienzustands für den Grund für den Tunnel-Absturz mit dem Befehl show tunnel interface tunnel x hidden angezeigt werden:
Router#show tunnel interface tunnel 100
Tunnel100
Mode:multi-GRE/IP, Destination UNKNOWN, Source GigabitEthernet0/1
Application ID 1: unspecified
Tunnel Subblocks:
src-track:
Tunnel100 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 2 members (includes
iterators), on interface <OK>
Linestate - current down
Internal linestate - current down, evaluated down - interface not up
Tunnel Source Flags: Local
Transport IPv4 Header DF bit cleared
OCE: IP tunnel decap
Provider: interface Tu100, prot 47
Performs protocol check [47]
Performs Address save check
Protocol Handler: GRE: key 0x64, opt 0x2000
ptype: ipv4 [ipv4 dispatcher: drop]
ptype: ipv6 [ipv6 dispatcher: drop]
ptype: mpls [mpls dispatcher: drop]
ptype: otv [mpls dispatcher: drop]
ptype: generic [mpls dispatcher: drop]
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
18-Oct-2023 |
Rezertifizierung |
2.0 |
25-Aug-2022 |
Erstveröffentlichung |
1.0 |
07-Nov-2014 |
Erstveröffentlichung |
Feedback