Bepaal welke effecten GRE-tunnelinterfacestanden hebben

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 van dit is dat, door gebrek, de lokale router van het tunneleindpunt niet de capaciteit heeft om het lijnprotocol van de interface van de tunnel te brengen GRE neer als het verre eind van de tunnel onbereikbaar is. De capaciteit om een interface zoals neer te merken wanneer het verre eind van de verbinding niet beschikbaar is wordt gebruikt om het even welke routes (specifiek statische routes) in de routeringstabel te verwijderen die die interface als uitgaande interface gebruiken. Specifiek, als het lijnprotocol voor een interface wordt veranderd in beneden, dan 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 staat verandert; bijvoorbeeld 'backup-interface <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 functioneel is en het verkeer passeert. Het is zowel administratief up als zijn protocol is ook up.
2. Administratief down/down - Dit impliceert dat de interface administratief is gesloten.
3. Up/Down - Dit impliceert dat, alhoewel de tunnel administratief omhoog is, iets veroorzaakt dat het lijnprotocol op de interface neer is.
4. 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 zou worden veranderd in een GRE (mGRE) tunnel met meerdere punten, dan is alles wat nodig is om de tunnel in een hogere staat te laten zijn een geldige tunnelbron (een mGRE-tunnel kan veel tunnelbestemmingen hebben, zodat deze niet gebruikt kan worden om de tunnelinterfacestand 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 administratief neer/neer in staat:

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 routable zoals aangetoond in de vorige sectie is.

Lijnprotocol lokaal omlaag op de router

Onder normale omstandigheden zijn er slechts drie redenen voor een GRE-tunnel om in de op/neer-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 en behandelen geen problemen in het tussenkomende netwerk of andere eigenschappen met betrekking tot de tunnel GRE die kunnen worden gevormd. In dit document worden scenario's beschreven waarbij andere factoren de toestand van de GRE-tunnel kunnen beïnvloeden.

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 gegevenspakketten die door de GRE-tunnel gaan "zwart gehold" te zijn, alhoewel 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 dit probleem op dezelfde manier op te lossen 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 tunnelkeepalives werken, verwijs naar GRE Tunnel Keepalives.

Opmerking: GRE-tunnelkeepalives zijn alleen geldig en hebben een effect op P2P GRE-tunnels; zij zijn ongeldig 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 kan de status van het protocol voor de GRE-tunnellijn de status van IPsec Security Association (SA) volgen, zodat het lijnprotocol omlaag kan blijven tot de IPsec-sessie volledig is voltooid. 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, aangezien er geen vaste tunnelbestemming is, zijn sommige van de voorgaande controles voor P2P-tunnels niet van toepassing. Hier zijn de redenen een mGRE tunnellijnprotocol in een benedenstaat kan zijn:

• De tunnelbroninterface is in een benedenstaat.
• Als de functie Interface State Control is ingeschakeld voor Dynamic Multipoint VPN (DMVPN) en geen van de NHS’s reageert, dan wordt het lijnprotocol in de status Down gezet. Zie de configuratiehandleiding voor de DMVPN Tunnel Health Monitoring and Recovery voor meer informatie over de interfacestationbeheerfunctie.

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 voegde een extra 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 uiteengezette redenen kan de evaluatie van de toestand van de tunnellijn voor de tunnel beneden reden worden gezien met de show tunnel interface tunnel x verborgen opdracht zoals hier getoond:

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 beneden reden explicieter te maken om erop te wijzen dat het toe te schrijven is aan de overtolligheidsstaat omdat het niet actief is. Dit wordt gevolgd door Cisco bug-id CSCuq31060.

Gerelateerde informatie

• RFC 1701, Generic Router Encapsulation (GRE)
• RFC 2890: Uitbreidingen van sleutel- en volgnummer naar GRE
• Generic Routing Encapsulation (GRE)-tunnelbehoud
• IP-fragmentatie en PMTUD
• Technische ondersteuning en documentatie – Cisco Systems