Déterminer l'impact des états d'interface de tunnel GRE

Introduction

Ce document décrit les différentes conditions qui peuvent toucher l’état d’une interface de tunnel GRE (Generic Routing Encapsulation).

Informations générales

Les tunnels GRE sont conçus pour être totalement sans état. Cela signifie que chaque point de terminaison du tunnel ne conserve aucune information sur l'état ou la disponibilité du point de terminaison du tunnel distant.

Par conséquent, par défaut, le routeur du point d'extrémité du tunnel local ne peut pas désactiver le protocole de ligne de l'interface du tunnel GRE si l'extrémité distante du tunnel est inaccessible.

La possibilité de marquer une interface comme « désactivée » (dans cette situation) est utilisée afin de supprimer toutes les routes statiques dans la table de routage qui utilisent cette interface comme interface de sortie.

Plus précisément, si le protocole de ligne d’une interface est modifié en « down », toutes les routes statiques indiquant cette interface sont supprimées de la table de routage.

Cela permet l'installation d'une route statique alternative (flottante) ou d'un PBR (Policy Based Routing) afin de sélectionner un saut suivant ou une interface alternative.

En outre, d'autres applications se déclenchent lorsqu'une interface change d'état ; par exemple, « interface de sauvegarde <b-interface> ».

Quatre états de tunnel différents

Il existe quatre états possibles dans lesquels une interface de tunnel GRE existe :

1. Up/up : cela signifie que le tunnel est entièrement fonctionnel et transmet le trafic. Il est à la fois actif sur le plan administratif et son protocole est également actif.
2. Administratively down/down : cela signifie que l'interface a été désactivée administrativement.
3. Up/down : cela implique que, même si le tunnel est administrativement up, quelque chose provoque l'arrêt du protocole de ligne sur l'interface.
4. Reset/down : il s'agit généralement d'un état transitoire lorsque le tunnel est réinitialisé par le logiciel. Cela se produit généralement lorsque le tunnel est mal configuré avec un serveur de tronçon suivant (NHS) qui est sa propre adresse IP.

Lorsqu'une interface de tunnel est créée pour la première fois et qu'aucune autre configuration ne lui est appliquée, l'interface n'est pas fermée par défaut :

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

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

Dans cet état, l'interface est toujours active/inactive :

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

En effet, l'interface est administrativement activée, mais comme elle n'a pas de source ou de destination de tunnel, le protocole de ligne est désactivé.

Afin de rendre cette interface active/active, une source et une destination de tunnel valides doivent être configurées :

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      

La séquence précédente montre que :

• Une source de tunnel valide est constituée de n'importe quelle interface qui est elle-même dans l'état up/up et qui a une adresse IP configurée dessus.
• Par exemple, si la source du tunnel a été changée en Loopback0, l'interface du tunnel serait désactivée même si Loopback0 est dans l'état up/up :
  
  

  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

• Une destination de tunnel valide est une destination routable. Cependant, il n'est pas nécessaire qu'elle soit accessible, comme le montre ce test ping :
  
  

  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)

Jusqu'à présent, le tunnel a été configuré en tant que tunnel GRE point à point (P2P), qui est le tunnel par défaut.

Si ce tunnel devait être remplacé par un tunnel GRE multipoint (mGRE), alors tout ce qui est requis pour un état up est une source de tunnel valide. 

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    

À tout moment, si l'interface du tunnel est désactivée par l'administrateur, le tunnel passe immédiatement à l'état administratively down/down :

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    

État du tunnel P2P GRE

Une interface de tunnel P2P GRE apparaît généralement dès qu'elle est configurée avec une adresse source de tunnel valide ou une interface qui est active et une adresse IP de destination de tunnel qui est routable (montrée précédemment).

Protocole de ligne désactivé localement sur le routeur

Dans des circonstances normales, il n'y a que trois raisons pour qu'un tunnel GRE soit à l'état up/down :  

• Il n'existe aucune route, qui inclut la route par défaut, vers l'adresse de destination du tunnel.
• L'interface qui ancre la source de tunnel est désactivée.
• La route vers l'adresse de destination du tunnel passe par le tunnel lui-même, ce qui entraîne une récursivité.

Ces trois règles (missingroute, interface désactivée et destination de tunnel mal routée) sont des problèmes locaux au routeur aux points d'extrémité du tunnel. 

Ils ne couvrent pas les problèmes du réseau intermédiaire ou d'autres fonctionnalités liées au tunnel GRE qui peuvent être configurées. Ce document décrit des scénarios dans lesquels d'autres facteurs peuvent influencer l'état du tunnel GRE.

Keepalives de tunnel GRE

Les règles de base ne couvrent pas le cas où les paquets en tunnel GRE sont transférés avec succès mais perdus avant d'atteindre l'autre extrémité du tunnel.

Cela entraîne la perte des paquets de données qui passent par le tunnel GRE, même si une autre route qui utilise PBR ou une route statique flottante via une autre interface est potentiellement disponible.

Les keepalives sur l'interface de tunnel GRE sont utilisés afin de résoudre ce problème de la même manière que les keepalives sont utilisés sur les interfaces physiques.

Avec le logiciel Cisco IOS® version 12.2(8)T, il est possible de configurer des keepalives sur une interface de tunnel P2P GRE. Avec cette modification, l'interface du tunnel s'arrête de manière dynamique si les keepalives échouent pendant une certaine durée. 

Afin de mieux comprendre comment les keepalives de tunnel GRE fonctionnent, référez-vous à Keepalives de tunnel GRE.

Remarque : les keepalives de tunnel GRE sont uniquement valides et ont un effet sur les tunnels GRE P2P ; ils ne sont pas valides et n'ont aucun effet sur les tunnels mGRE.

Tunnels GRE avec protection de tunnel

Dans les versions du logiciel Cisco IOS® 15.4(3)M/15.4(3)S et ultérieures, l'état du protocole de ligne de tunnel GRE suit l'état de l'association de sécurité IPsec. Par conséquent, le protocole de ligne peut rester inactif jusqu'à ce que la session IPsec soit entièrement établie.

Ceci a été validé avec l'ID de bogue Cisco CSCum34057 (tentative initiale avec l'ID de bogue Cisco CSCuj29996 et ensuite effacé avec l'ID de bogue Cisco CSCuj99287).

Interfaces de tunnel Multipoint GRE (mGRE)

Pour les interfaces de tunnel mGRE, certaines des vérifications précédentes pour les tunnels P2P ne sont pas applicables (car il n'y a pas de destination de tunnel fixe).

Voici les raisons pour lesquelles un protocole de ligne de tunnel mGRE peut être dans un état down :

• L'interface source du tunnel est désactivée.
• Si la fonction de contrôle d'état d'interface est activée pour le VPN multipoint dynamique (DMVPN) et qu'aucun NHS ne répond, le protocole de ligne est mis en état down.
• Pour plus d'informations sur la fonctionnalité de contrôle d'état d'interface, consultez le Guide de configuration de la surveillance de l'état et de la récupération du tunnel DMVPN.

Dépendances sur l'état de redondance

Lorsqu'une adresse IP source de tunnel est configurée en tant qu'adresse IP de redondance (par exemple, une adresse IP virtuelle HSRP (Hot Standby Router Protocol Virtual IP)), l'état de l'interface du tunnel effectue le suivi de l'état de redondance.

Ceci ajoute une autre vérification qui maintient ces interfaces de tunnel dans l'état de ligne du protocole down jusqu'à ce que l'état de redondance passe à ACTIVE.

Dans cet exemple, une configuration par défaut de zone ipc mal configurée provoque la redondance dans l'état NEGOTIATION et maintient ces interfaces de tunnel dans un état down :

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>

Dépannage

En plus des raisons décrites précédemment, l'évaluation de l'état de la ligne de tunnel pour la raison de tunnel down peut être vue avec la commande show tunnel interface tunnel x hidden :

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] 

Remarque : il existe une amélioration ouverte pour rendre la raison de désactivation du tunnel plus explicite afin d'indiquer qu'elle est due à l'état de redondance car elle n'est pas active. Ce problème est suivi par l'ID de bogue Cisco CSCuq31060.

Informations connexes

• RFC 1701, Generic Router Encapsulation (GRE)
• RFC 2890, Extensions de clé et de numéro de séquence à GRE
• Keepalive de tunnel GRE (Generic Routing Encapsulation)
• Fragmentation IP et PMTUD
• Assistance et documentation techniques - Cisco Systems