GRE-tunnelinterfacestaten en wat hiervan de invloed is

Inleiding

Dit document beschrijft de verschillende voorwaarden die de staat van een Generic Routing Encapsulation (GRE)-tunnelinterface kunnen beïnvloeden.

Achtergrondinformatie

GRE-tunnels zijn ontworpen om volledig stateloos te zijn. Dit betekent dat elk tunneleindpunt geen informatie over de staat of beschikbaarheid van het afstandstunneleindpunt houdt. Een gevolg hiervan is dat, standaard, de lokale router voor tunneleindpunt niet de mogelijkheid heeft om het lijnprotocol van de GRE Tunnel interface omlaag te brengen als het verre uiteinde van de tunnel onbereikbaar is. De mogelijkheid om een interface vanaf het eind op afstand van de verbinding te markeren wordt niet beschikbaar gebruikt om routes (specifiek statische routes) in de routingtabel te verwijderen die die interface als de uitgaande interface gebruiken. In het bijzonder, als het lijnprotocol voor een interface wordt veranderd in neer, dan zouden om het even welke statische routes die erop wijzen dat de interface uit de routingtabel wordt verwijderd. Dit staat voor de installatie van een alternatieve (drijvende) statische route of voor beleid gebaseerde routing (PBR) toe om een alternatieve volgende-hop of interface te selecteren. Er zijn ook andere toepassingen die geactiveerd worden wanneer een interface de status verandert; Bijvoorbeeld 'back-upinterface <b-interface>'.

Vier verschillende tunnelstaten

Er zijn vier mogelijke staten waarin een GRE-tunnelinterface kan zijn:

1. Up/up - Dit betekent dat de tunnel volledig functioneert en door het verkeer rijdt. Het is zowel administratief hoger als het protocol is er ook.
2. Administratief afsluiten/afsluiten - Dit impliceert dat de interface administratief is uitgeschakeld.
3. Omhoog/omlaag - Dit betekent dat, ook al is de tunnel administratief omhoog, er iets is dat het lijnprotocol op de interface omlaag brengt.
4. Reset/Down - Dit is meestal een tijdelijke toestand wanneer de tunnel door software wordt gereset. Dit gebeurt meestal wanneer de tunnel verkeerd is geconfigureerd met een Next Hop Server (NHS), die het eigen IP-adres is.

Wanneer een tunnelinterface eerst wordt gecreëerd en er geen andere configuratie op wordt toegepast, wordt de interface standaard niet uitgeschakeld:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 40 bytes
!
interface Tunnel1
 no ip address
end

In deze toestand wordt de interface altijd omhoog/omlaag gebracht:

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         14.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 is ingeschakeld, maar omdat er geen tunnelbron of tunnelbestemming is, is het lijnprotocol minder.

Om deze interface op/omhoog te maken, moet een geldige tunnelbron en tunnelbestemming worden geconfigureerd:

Router#show run interface tunnel  1
Building configuration...

Current configuration : 113 bytes
!
interface Tunnel1
 ip address 1.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         14.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                    1.1.1.1         YES manual up                    up      

Uit de vorige volgorde blijkt dat:

• Een geldige tunnelbron bestaat uit elke interface die zelf in de omhoog/omhoog staat en er een IP-adres op is ingesteld. Bijvoorbeeld, als de tunnelbron werd veranderd in Loopback0, zou de tunnelinterface dalen zelfs alhoewel Loopback0 in de omhoog/omhoog staat:
  
  

  Router(config-if)#int tun 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 een die routeerbaar is. Dit hoeft echter niet bereikbaar te zijn, zoals blijkt uit deze pingtest:
  
  

  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 standaardinstelling is. Als deze tunnel zou worden veranderd in een GRE-tunnel (mGRE) met meerdere punten, dan is alles wat nodig is om de tunnel in een hogere toestand te kunnen plaatsen een geldige tunnelbron (een mGRE-tunnel kan vele tunnelbestemmingen hebben, zodat deze niet kan worden gebruikt om de tunnelinterfacestatus te te controleren):

Router#show run interface tunnel 1
Building configuration...

Current configuration : 129 bytes
!
interface Tunnel1
 ip address 1.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                    1.1.1.1         YES manual up                    up    

Als de tunnelinterface administratief wordt afgesloten, gaat de tunnel op elk punt onmiddellijk in een administratieve stilstand:

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-tunnelstaat

Normaal gesproken wordt een P2P GRE-tunnelinterface ingeschakeld zodra deze is ingesteld met een geldig adres of een geldige tunnelbron en een IP-adres voor tunnelbestemming dat routeerbaar is, zoals in de vorige sectie wordt getoond.

Het Protocol van de lijn ligt lokaal op de router

Onder normale omstandigheden zijn er slechts drie redenen om een GRE-tunnel in de omhoog/omlaag-stand te houden:  

• Er is geen route, die de standaardroute omvat, naar het adres van de tunnelbestemming.
• De interface die de tunnelbron verankert is omlaag.
• De route naar het adres van de tunnelbestemming is door de tunnel zelf, wat leidt tot recursie.

Deze drie regels (ontbrekende route, interface down, en misrouteerde tunnelbestemming) zijn problemen lokaal aan de router bij de tunneleindpunten en behandelen geen problemen in het tussenliggende netwerk of andere eigenschappen die met de GRE-tunnel verband kunnen worden gehouden die zouden kunnen worden gevormd. In dit document worden scenario's beschreven waar andere factoren van invloed kunnen zijn op de toestand van de GRE-tunnel.

GRE-tunnelzijnen

De basisregels hebben geen betrekking op het geval waarin de GRE-tunnelpakketten met succes worden doorgestuurd, maar verloren zijn voordat zij het andere uiteinde van de tunnel bereiken. Dit veroorzaakt gegevenspakketten die door de GRE-tunnel gaan "zwart gehouden" zijn, zelfs als een alternatieve route die PBR of een zwevende statische route via een andere interface gebruikt, potentieel beschikbaar is. Keepalives op de GRE-tunnelinterface worden gebruikt om deze kwestie op dezelfde manier op te lossen als keepalives op fysieke interfaces worden gebruikt.

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 tunnel interface dynamisch af als de keepalives gedurende een bepaalde tijd falen. Om beter te begrijpen hoe GRE tunnel het werk behoudt, verwijs naar GRE Tunnel Keepalives.

Opmerking: GRE-tunnelkeepaliven zijn alleen geldig en hebben een effect op P2P GRE-tunnels; zij zijn niet geldig en hebben geen effect op de tunnels van mGRE.

GRE-tunnels met tunnelbescherming

In Cisco IOS-softwarereleases 15.4(3)M/15.4(3)S en later zal de status van het GRE-tunnelprotocol de status van IPsec Security Association (SA) volgen, zodat het lijnprotocol laag blijft tot de IPsec-sessie volledig is ingesteld. Dit is uitgevoerd met Cisco bug-ID CSCum34057 (eerste poging met Cisco bug-ID CSCuj29996 en vervolgens ondersteund door Cisco bug-ID CSCuj9287).

Multipoint GRE (mGRE) tunnelinterfaces

Voor mGRE-tunnelinterfaces, aangezien er geen vaste tunnelbestemming is, zijn sommige van de vorige controles voor P2P-tunnels niet van toepassing. Hier zijn de redenen dat het lijnprotocol van een mGRE-tunnel in een benedenstaat kan zijn:

• De tunnelbroninterface is in een lagere toestand.
• Als de optie Interfacestudy Control is ingeschakeld voor Dynamic Multipoint VPN (DMVPN) en geen van de NHS’s reageert, dan wordt het lijnprotocol in een lagere status geplaatst. Zie de configuratiegids voor de bewaking en herstel van de gezondheid van de DMVPN-tunnelfunctie voor meer informatie over de interfacefunctie staatscontrole.

Dependentie van de status redundantie

Wanneer een IP-adres van een tunnelbron wordt geconfigureerd als een IP-adres voor redundantie (bijvoorbeeld een HSRP VIP-adres (Hot Standby Router Protocol Virtual IP), dan volgt de status van de tunnelinterface de redundantie-status.

Dit voegde een extra controle toe, die zulke tunnelinterfaces in de status van het lijnprotocol onderhoudt tot de staat van de overtolligheid in ACTIEF verandert. In dit voorbeeld veroorzaakt een verkeerd gevormde ipc zone configuratie redundantie in de staat van de ONDERHANDELING 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 het controleren van de eerder geschetste redenen, kan de evaluatie van de tunnellijn voor de tunnelomlaag reden worden gezien met de hier weergegeven verborgen opdracht van de tunnelinterface x:

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 tunnelrede explicieter te maken om aan te geven dat de redundantiestaat niet actief is. Dit wordt gevolgd door Cisco bug-ID CSCuq31060.

Gerelateerde informatie

• RFC 1701, Generic Router Encapsulation (GRE)
• RFC 2890, toetsuitbreidingen en sequentienummer aan GRE
• Generic Routing Encapsulation (GRE) Tunnel Keeplive
• IP-fragmentatie en PMTUD
• Technische ondersteuning en documentatie – Cisco Systems