Contenu

Introduction

Informations générales

Quatre états de tunnel différents

État du tunnel P2P GRE

Protocole de ligne désactivé localement sur le routeur

Keepalives de tunnel GRE

Tunnels GRE avec protection de tunnel

Interfaces de tunnel Multipoint GRE (mGRE)

Dépendances sur l'état de redondance

Dépannage

Informations connexes

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 n'a pas la capacité d'arrêter le protocole de ligne de l'interface du 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. 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. Il existe également d'autres applications qui se déclenchent lorsqu'une interface change d'état ; par exemple, 'backup interface <b-interface>'.

Quatre états de tunnel différents

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

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 toute 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é comme tunnel GRE point à point (P2P), qui est le tunnel par défaut. Si ce tunnel devait être changé en tunnel multipoint GRE (mGRE), alors tout ce qui est requis pour que le tunnel soit dans un état up est une source de tunnel valide (un tunnel mGRE peut avoir de nombreuses destinations de tunnel, de sorte qu'il ne peut pas être utilisé pour contrôler l'état de l'interface du tunnel) :

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 comme indiqué dans la section précédente.

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 (missing, route, interface désactivée et destination du tunnel mal routé) sont des problèmes locaux au routeur aux points d'extrémité du tunnel et ne couvrent pas les problèmes dans le 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 où d'autres facteurs peuvent influencer l'état du tunnel GRE.

Keepalives de tunnel GRE

Les règles de base ne couvrent pas le cas dans lequel les paquets en tunnel GRE sont transférés avec succès, mais sont perdus avant d'atteindre 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. 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 ce changement, l'interface de tunnel s'arrête dynamiquement si les keepalives échouent pendant un certain temps. Afin de mieux comprendre comment les keepalives de tunnel GRE fonctionnent, référez-vous à GRE Tunnel Keepalives.

Note: 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 du tunnel GRE peut suivre l'état de l'association de sécurité IPsec, de sorte que 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, comme il n'y a pas de destination de tunnel fixe, certaines des vérifications précédentes pour les tunnels P2P ne sont pas applicables. 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 des 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 surveillance de l'état et de 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.

Cela a ajouté une vérification supplémentaire, qui maintient ces interfaces de tunnel dans l'état « line protocol 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 comme montré 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 rendre la raison de désactivation du tunnel plus explicite afin d'indiquer qu'elle est due à l'état de redondance parce qu'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

- Support et documentation techniques - Cisco Systems