États d'interface de tunnel GRE et ce qui les affecte

Introduction

Ce document décrit les différentes conditions qui peuvent affecter l'état d'une interface de tunnel d'Encapsulation de routage générique (GRE).

Informations générales

Les tunnels GRE sont conçus pour être totalement sans état. Ceci signifie que chaque périphérique du tunnel ne garde aucune information sur l'état ou Disponibilité du périphérique du tunnel distant. Une conséquence de ceci est que, par défaut, le routeur local de périphérique du tunnel n'a pas la capacité de réduire la ligne protocole de l'interface de tunnel GRE si l'extrémité distante du tunnel est inaccessible. La capacité à marquer une interface comme désactivée quand l'extrémité distante de la liaison n'est pas disponible est utilisée afin de supprimer toutes les routes (spécifiquement les routes statiques) dans la table de routage qui utilisent cette interface comme interface de sortie. Spécifiquement, si le protocole de ligne pour une interface est modifié comme étant désactivé, toutes les routes statiques qui pointent vers cette interface sont supprimées de la table de routage. Ceci tient compte pour l'installation d'une artère statique (de flottement) alternative ou du Routage à base de règles (PBR) afin de sélectionner un prochain-saut ou une interface alternatif. Également il y a d'autres applications qui déclenchent quand une interface change l'état ; par exemple, « <b-interface> d'Interface de sauvegarde ».

Quatre états du tunnel différents

Il y a quatre états possibles dans lesquels une interface de tunnel GRE peut être :

1. Up/up - Ceci implique que le tunnel est entièrement - fonctionnel et des passages trafiquez. Il est tous deux administrativement hauts et c'est protocole est aussi bien.
2. Administrativement en bas de/vers le bas - Ceci implique que l'interface a été administrativement arrêtée.
3. Haut/bas - Ceci implique que, quoique le tunnel soit administrativement, quelque chose fait être la ligne protocole sur l'interface en baisse.
4. Remise/vers le bas - C'est habituellement un état transitoire quand le tunnel est remis à l'état initial par le logiciel. Ceci se produit habituellement quand le tunnel misconfigured avec un prochain serveur de saut (NHS) qui est lui doit posséder l'adresse IP.

Quand une interface de tunnel est d'abord créée et aucune autre configuration n'est appliquée à elle, 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 haut/bas :

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

C'est parce que l'interface est administrativement activée, mais puisqu'elle n'a pas une source du tunnel ou une destination de tunnel, la ligne protocole est en baisse.

Afin de faire cette interface up/up, une destination valide de source du tunnel et de tunnel doit être configurée :

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      

L'ordre précédent affiche cela :

• Une source du tunnel valide se compose de n'importe quelle interface qui est elle-même dans l'état up/up et a une adresse IP configurée là-dessus. Par exemple, si la source du tunnel était changée à Loopback0, l'interface de tunnel descendrait quoique Loopback0 soit dans l'état up/up :
  
  

  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

• Une destination valide de tunnel est une qui est routable. Cependant, il ne doit pas être accessible, qui peut être vu de ce test de 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'ici, le tunnel a été configuré pendant qu'un tunnel de Point à point (P2P) GRE, qui est le par défaut. Si ce tunnel devaient être changés à un tunnel multipoint GRE (mGRE), alors tout ce qui est exigé pour que le tunnel soit dans un état haut est une source du tunnel valide (un tunnel de mGRE peut avoir beaucoup de destinations de tunnel, de sorte que ne puisse pas être utilisé pour contrôler l'état d'interface de tunnel) :

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    

À un point quelconque, si l'interface de tunnel est administrativement arrêtée, le tunnel entre immédiatement dans administrativement vers le bas/état d'indisponibilité :

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 du P2P GRE

Normalement, une interface de tunnel du P2P GRE est soulevée dès qu'elle sera configurée avec une adresse de source du tunnel ou une interface valide qui est en hausse et une adresse IP de destination de tunnel qui est routable suivant les indications de la section précédente.

Ligne Protocol vers le bas localement sur le routeur

Sous des circonstances normales, il y a seulement trois raisons pour qu'un tunnel GRE soit dans l'état haut/bas :  

• Il n'y a aucune artère, qui inclut le default route, à l'adresse de destination de tunnel.
• L'interface qui ancre la source de tunnel est désactivée.
• L'artère à l'adresse de destination de tunnel est par le tunnel lui-même, qui a comme conséquence la récursion.

Ces trois règles (manquant l'artère, l'interface vers le bas, et la destination misrouted de tunnel) sont des problèmes locaux au routeur aux périphériques du tunnel et ne couvrent pas des problèmes dans le réseau intervenant ou autre comporte connexe au tunnel GRE qui pourrait être configuré. Ce document décrit des scénarios où d'autres facteurs pourraient influencer l'état du tunnel GRE.

Keepalives de tunnel GRE

Les principes de base ne couvrent pas le cas en lequel le GRE a percé un tunnel des paquets est avec succès expédié, mais est perdu avant qu'ils atteignent l'autre extrémité du tunnel. Ceci provoque la chute des paquets de données qui passent par le tunnel GRE dans un « trou noir », bien qu'une route alternative qui utilise PBR ou une route statique flottante via une autre interface soit potentiellement disponible. Le Keepalives sur l'interface de tunnel GRE est utilisé afin de résoudre le Keepalives de cette question de la même manière est utilisé sur des interfaces physiques.

Avec la version de logiciel 12.2(8)T de Cisco IOS®, il est possible de configurer le Keepalives sur une interface de tunnel du 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 comprendre mieux comment le Keepalives de tunnel GRE fonctionne, référez-vous au Keepalives de tunnel GRE.

Note: Le Keepalives de tunnel GRE est seulement valide et exerce un effet sur des tunnels du P2P GRE ; ils sont non valides et n'exercent pas n'importe quel effet sur des tunnels de mGRE.

Tunnels GRE avec le tunnel protection

Dans des versions du logiciel Cisco IOS 15.4(3)M/15.4(3)S et plus tard, la ligne état de tunnel GRE de protocole suivra l'état de l'association de sécurité IPSec (SA), ainsi la ligne protocole demeurera vers le bas jusqu'à ce que la session d'IPsec soit entièrement établie. Ceci a été commis avec l'ID de bogue Cisco CSCum34057 (tentative initiale avec ID de bogue Cisco CSCuj29996 et alors soutenu avec ID de bogue Cisco CSCuj99287).

Interfaces de tunnel multipoints GRE (mGRE)

Pour des interfaces de tunnel de mGRE, puisqu'il n'y a aucune destination fixe de tunnel, une partie du précédent vérifie des tunnels de P2P s'applique pas applicable. Voici les raisons que la ligne protocole d'un tunnel de mGRE peut être dans un état d'indisponibilité :

• L'interface de source du tunnel est dans un état d'indisponibilité.
• Si la caractéristique de contrôle de l'État d'interface est activée pour le VPN multipoint dynamique (DMVPN) et aucun du NHSs ne répond, alors la ligne protocole est mise dans un état d'indisponibilité. Pour des détails sur la caractéristique de contrôle de l'État d'interface, voyez le guide de configuration de surveillance de la santé et de reprise de tunnel DMVPN.

Dépendances sur l'état de Redondance

Quand une adresse IP de source du tunnel est configurée pendant qu'une adresse IP de Redondance (par exemple, une adresse virtuelle IP de Protocol de routeur de secours immédiat (VIP de HSRP)), alors l'état d'interface de tunnel dépiste l'état de Redondance.

Ceci a ajouté un contrôle supplémentaire, qui maintient de telles interfaces de tunnel dans la ligne état d'indisponibilité de protocole jusqu'aux modifications d'état de Redondance à l'ACTIVE. Dans cet exemple, une configuration d'ipc zone default misconfigured fait être la Redondance dans l'état de NÉGOCIATION et maintient de telles interfaces de tunnel dans un état d'indisponibilité :

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épanner

En plus de vérifier les raisons précédemment tracées les grandes lignes, l'état de la ligne de tunnel que l'évaluation pour le tunnel raisonnent vers le bas peut être vu avec la commande masquée du tunnel X d'interface de tunnel d'exposition comme affiché ici :

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] 

Note: Il y a une amélioration ouverte pour faire le tunnel vers le bas raisonner plus explicite afin d'indiquer qu'il est dû à l'état de Redondance n'étant pas actif. Ceci est dépisté 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
• Support et documentation techniques - Cisco Systems