Déterminer l'impact des états d'interface de tunnel GRE
Table des matières
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 :
- 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.
- Administratively down/down : cela signifie que l'interface a été désactivée administrativement.
- 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.
- 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.
Remarque : un tunnel mGRE peut avoir de nombreuses destinations de tunnel, qui ne peuvent donc pas être utilisées 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 (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 (missing, route, interface désactivée et destination du tunnel mal routé) sont des problèmes locaux au routeur au niveau des 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.
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]
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
4.0 |
18-Oct-2023 |
Recertification |
2.0 |
25-Aug-2022 |
Première publication |
1.0 |
07-Nov-2014 |
Première publication |
Commentaires