Inleiding
In dit document worden de verschillende omstandigheden beschreven die de status van een GRE-tunnelinterface (Generic Routing Encapsulation) kunnen beïnvloeden.
Achtergrondinformatie
GRE-tunnels zijn ontworpen om volledig stateloos te zijn. Dit betekent dat elk tunneleindpunt geen informatie houdt over de toestand of beschikbaarheid van het tunneleindpunt op afstand.
Een gevolg is dat, door gebrek, de lokale router van het tunneleindpunt niet het lijnprotocol van de interface van de tunnel kan neer brengen GRE als het verre eind van de tunnel onbereikbaar is.
De capaciteit om een interface als "neer" (in deze situatie) te merken wordt gebruikt om het even welke statische routes in de routeringstabel te verwijderen die die interface als uitgaande interface gebruiken.
Specifiek, als het lijnprotocol voor een interface wordt veranderd in "onderaan", om het even welke statische routes die erop wijzen dat de interface wordt verwijderd uit de routeringstabel.
Dit maakt de installatie van een alternatieve (zwevende) statische route of voor op beleid gebaseerde routing (PBR) mogelijk om een alternatieve next-hop of interface te selecteren.
Er zijn ook andere toepassingen die activeren wanneer een interface van status verandert; bijvoorbeeld 'backup-interface <b-interface>'.
Vier verschillende tunnelstaten
Er zijn vier mogelijke toestanden waarin een GRE-tunnelinterface bestaat:
- Up/Up - Dit betekent dat de tunnel volledig functioneel is en het verkeer passeert. Het is zowel administratief up als zijn protocol is ook up.
- Administratief down/down - Dit impliceert dat de interface administratief is gesloten.
- Up/Down - Dit impliceert dat, alhoewel de tunnel administratief omhoog is, iets veroorzaakt dat het lijnprotocol op de interface neer is.
- Reset/down - Dit is gewoonlijk een voorbijgaande staat wanneer de tunnel door software wordt teruggesteld. Dit gebeurt meestal wanneer de tunnel verkeerd is geconfigureerd met een Next Hop Server (NHS) die zijn eigen IP-adres is.
Wanneer een tunnelinterface eerst wordt gecreëerd en er geen andere configuratie op wordt toegepast, wordt de interface niet standaard gesloten:
Router#show run interface tunnel 1
Building configuration...
Current configuration : 40 bytes
!
interface Tunnel1
no ip address
end
In deze staat is de interface altijd omhoog/omlaag:
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
Dit is omdat de interface administratief wordt toegelaten, maar aangezien het geen tunnelbron of een tunnelbestemming heeft, is het lijnprotocol neer.
Om deze interface up/up te maken, moeten een geldige tunnelbron en een tunnelbestemming worden geconfigureerd:
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
Uit de vorige sequentie blijkt dat:
- Een geldige tunnelbron bestaat uit elke interface die zelf in de up/up staat is en een IP adres heeft dat op het wordt gevormd.
- Bijvoorbeeld, als de tunnelbron werd veranderd in Loopback0, zou de tunnelinterface dalen alhoewel Loopback0 in de staat up/up is:
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
- Een geldige tunnelbestemming is routable. Echter, het hoeft niet bereikbaar te zijn, wat kan worden gezien van deze ping test:
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)
Tot nu toe is de tunnel geconfigureerd als een point-to-point (P2P) GRE-tunnel, wat de standaard is.
Als deze tunnel veranderd zou worden in een multipoint GRE (mGRE) tunnel, dan is alles wat nodig is voor een up staat een geldige tunnelbron.
Opmerking: een mGRE-tunnel kan veel tunnelbestemmingen hebben, zodat hij niet kan worden gebruikt om de tunnelinterfacestatus te controleren.
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
Op elk punt, als de tunnelinterface administratief wordt afgesloten, gaat de tunnel onmiddellijk in een administratief beneden/benedenstaat:
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
Een P2P GRE Tunnel interface komt gewoonlijk omhoog zodra het met een geldig tunnelbronadres of interface wordt gevormd die omhoog en een IP van de tunnelbestemming adres is dat (eerder getoond) routable is.
Lijnprotocol lokaal omlaag op de router
Onder normale omstandigheden zijn er slechts drie redenen voor een GRE-tunnel om in de op- en neerwaartse staat te zijn:
- Er is geen route, die de standaardroute omvat, naar het adres van de tunnelbestemming.
- De interface die de tunnelbron verankert is beneden.
- De route naar het adres van de tunnelbestemming loopt door de tunnel zelf, wat resulteert in een terugkeer.
Deze drie regels (missing, route, interface omlaag, en verkeerd gerouteerde tunnelbestemming) zijn problemen lokaal aan de router bij de tunneleindpunten.
Zij behandelen geen problemen in het tussenliggende netwerk of andere eigenschappen met betrekking tot de tunnel GRE die kunnen worden gevormd. In dit document worden scenario's beschreven waarbij andere factoren van invloed kunnen zijn op de toestand van de GRE-tunnel.
GRE-tunnelkeepalives
De basisregels hebben geen betrekking op het geval waarin de pakketten met GRE-tunnels met succes worden doorgestuurd, maar verloren gaan voordat ze de andere kant van de tunnel bereiken.
Dit veroorzaakt dat gegevenspakketten die door de GRE-tunnel gaan, verloren gaan, alhoewel een alternatieve route die PBR of een drijvende statische route via een andere interface gebruikt potentieel beschikbaar is.
Keepalives op de GRE-tunnelinterface worden gebruikt om dit probleem op dezelfde manier op te lossen als keepalives worden gebruikt op fysieke interfaces.
Met Cisco IOS®-softwarerelease 12.2(8)T is het mogelijk om keepalives te configureren op een P2P GRE-tunnelinterface. Met deze verandering, sluit de tunnelinterface dynamisch af als keepalives voor een bepaalde periode ontbreken.
Om beter te begrijpen hoe GRE tunnel keepalives werken, verwijzen we naar GRE Tunnel Keepalives.
Opmerking: GRE tunnelkeepalives zijn alleen geldig en hebben een effect op P2P GRE tunnels; ze zijn niet geldig en hebben geen effect op mGRE tunnels.
GRE-tunnels met tunnelbescherming
In Cisco IOS®-softwarereleases 15.4(3)M/15.4(3)S en hoger wordt de status van het GRE-tunnelprotocol bepaald door de staat van de IPsec Security Association (SA). Daarom kan het lijnprotocol omlaag blijven tot de IPsec-sessie volledig is ingesteld.
Dit is gebeurd met Cisco bug-id CSCum34057 (eerste poging met Cisco bug-id CSCuj2996 en vervolgens back-up met Cisco bug-id CSCuj9287).
Multipoint GRE (mGRE) tunnelinterfaces
Voor mGRE-tunnelinterfaces zijn sommige van de voorgaande controles voor P2P-tunnels niet van toepassing (omdat er geen vaste tunnelbestemming is).
Hier zijn de redenen een mGRE tunnellijnprotocol in een benedenstaat kan zijn:
Afhankelijkheden van redundantiestatus
Wanneer een IP-adres van een tunnelbron is geconfigureerd als een IP-adres voor redundantie (bijvoorbeeld een HSRP VIP-adres (Hot Standby Router Protocol Virtual IP)), volgt de status van de tunnelinterface de redundantiestatus.
Dit voegt een andere controle toe die dergelijke tunnelinterfaces in het lijnprotocol onderaan staat houdt tot de overtolligheidsstaat in ACTIEF verandert.
In dit voorbeeld, veroorzaakt een verkeerd gevormde ipc zone standaard configuratie redundantie om in de ONDERHANDELINGSstaat te zijn en houdt dergelijke tunnelinterfaces in een benedenstaat:
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>
Problemen oplossen
Naast de eerder geschetste redenen, kan de evaluatie van de tunnellijnstaat voor de tunnel beneden reden worden gezien met de show tunnel interface tunnel x verborgen bevel:
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]
Opmerking: Er is een open verbetering om de tunnel omlaag reden explicieter te maken om aan te geven dat het te wijten is aan de redundantie status omdat het niet actief is. Dit wordt gevolgd door Cisco bug-id CSCuq31060.
Gerelateerde informatie