Une interface de tunnel GRE bloquée à l'état Down est une courte liste de contrôle mécanique, pas un mystère — mode d'encapsulation, adressage source/destination, clé GRE, route vers l'extrémité distante, et configuration du Keepalive, vérifiés dans cet ordre. Voici la séquence de diagnostic, les commandes exactes pour chaque vérification, et le test pratique par taille de ping qui trouve un plafond silencieux de MTU/fragmentation avant qu'il ne fasse tomber un tunnel sous charge.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Sept éléments de configuration décident si une interface de tunnel GRE monte — et la panne se ramène presque toujours exactement à l'un d'eux.
Une interface de tunnel GRE signalant Down est l'un des travaux de dépannage les plus mécaniques en routage — le modèle de classification des pannes qui le sous-tend liste sept éléments précis à vérifier, dans l'ordre : mode d'encapsulation, adressage IP, attribution source/destination, clé GRE, route sous-jacente vers la destination, configuration du keepalive, et dimensionnement MTU/MSS. Presque chaque ticket « le tunnel ne monte tout simplement pas » se résout à l'un de ces éléments.
Ceci diffère délibérément d'un tunnel déjà Up mais qui ne laisse pas passer correctement le trafic — c'est un problème de routage ou de détail d'encapsulation sur un tunnel qui existe déjà, et nous le traitons séparément dans notre note sur un tunnel VPN actif mais dont le ping échoue. Ce qui suit ici est ce qu'il faut vérifier avant même que l'interface de tunnel ne signale Up, plus la méthode de terrain pratique — tester avec différentes tailles de ping — pour trouver un plafond de MTU/fragmentation qu'une simple relecture de configuration ne révélera jamais.
Les pannes GRE se répartissent comme la plupart des pannes de tunnel : l'interface ne monte jamais, ou elle monte et quelque chose en aval ne va toujours pas.
Placer d'abord le symptôme sur cet arbre indique si vous êtes face à un problème d'établissement — cette note — ou à un problème de routage/encapsulation sur un tunnel qui existe déjà, ce qui relève d'un tout autre chemin de diagnostic.
Les légendes du schéma restent en anglais pour la clarté technique.
Tout ce qui figure sur la branche de gauche se lit directement dans la configuration et les compteurs propres de l'interface de tunnel — display this, display ip routing-table, display keepalive packets count. Une fois que l'interface signale Up, un diagnostic différent s'applique, et cela relève du territoire de la note complémentaire, pas de celle-ci.
Quatre vérifications dans l'ordre dont dépend l'interface de tunnel elle-même, plus le test de terrain pour le seul mode de panne qu'une relecture de configuration ne peut pas détecter.
display this sur l'interface de tunnel capture l'essentiel de ce qui empêche réellement un tunnel GRE de monter.
[HUAWEI-Tunnel0] display this
#
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
#
return
// confirm the peer's source/destination are the exact mirror of these two linesL'adresse de destination du tunnel doit être joignable via une route qui n'est pas le tunnel lui-même — c'est le piège de routage récursif le plus courant.
<Huawei> display ip routing-table
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.2/32 Static 60 0 20.1.1.2 GigabitEthernet0/0/1
// outbound interface is the physical uplink, not Tunnel0 -- this is correct
<Huawei> display ip interface brief
Interface IP Address/Mask Physical Protocol
Tunnel0 172.16.1.1/30 up upLe Keepalive GRE ne renseigne que sur la direction où il est activé — un tunnel peut sembler mort d'un côté et parfaitement sain de l'autre.
# This platform's Tunnel interface
interface Tunnel1
tunnel-protocol gre
keepalive period 10 // Cisco's minimum configurable period is 10s
source 2.2.2.2
destination 1.1.1.1
# Cisco's Tunnel interface (defaults to GRE already)
interface Tunnel1
keepalive 10 3
tunnel source Loopback0
tunnel destination 2.2.2.2
<Huawei> display keepalive packets count
Keepalive sent: 120 Reply received: 118
// sent greater than reply received -> packets lost toward the peer or on the way backC'est un test pratique, pas une vérification de configuration — à exécuter chaque fois que le tunnel monte bien mais chute sous trafic réel, ou ne reste pas stable sous charge.
<Huawei> ping -s 1400 -a 172.16.1.1 172.16.1.2
Request time out
<Huawei> ping -s 1350 -a 172.16.1.1 172.16.1.2
Reply from 172.16.1.2: bytes=1350 time=2 ms
// breakpoint found between 1350 and 1400 -- set the tunnel MTU at or below it
[HUAWEI-Tunnel0] mtu 1350
[HUAWEI-GigabitEthernet0/0/1] tcp adjust-mss 1300
// leave headroom under the tunnel MTU for GRE + IP + TCP header overheadUne fois que les vérifications ci-dessus ont indiqué où se situe le problème, ces cinq causes couvrent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEdisplay this sur l'interface Tunnel montre une configuration qui semble complète aux deux extrémités, mais l'état de l'interface reste Down.
CAUSELa destination de ce côté doit être la source du pair, et inversement, et le tunnel-protocol des deux extrémités doit correspondre exactement — un seul champ configuré avec la mauvaise adresse, ou un protocole laissé sur un mode différent, suffit, et ne produit d'erreur précise nulle part.
SOLUTIONLisez display this côte à côte sur les deux interfaces de tunnel et confirmez que source/destination sont l'exact miroir l'un de l'autre et que tunnel-protocol gre correspond aux deux extrémités.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
// peer's tunnel interface must show source 1.1.1.2 / destination (this end's source)SYMPTÔMETout dans la configuration du tunnel semble correct, mais l'interface ne monte jamais et rien dans les journaux n'indique pourquoi.
CAUSEgre key est une simple valeur partagée que les deux extrémités doivent configurer de façon identique ; une incohérence fait que l'extrémité réceptrice rejette silencieusement les paquets encapsulés GRE de l'extrémité distante, comme s'ils n'étaient jamais arrivés.
SOLUTIONConfirmez que la même valeur exacte de gre key est configurée sur les deux interfaces de tunnel — il n'existe aucune tolérance de correspondance partielle.
SYMPTÔMEL'interface de tunnel monte, puis chute, puis remonte — de façon répétée — sans problème évident de liaison ou de matériel.
CAUSESoit il n'existe aucune route vers l'adresse de destination du tunnel, soit la route existante repointe vers l'interface de tunnel elle-même (boucle de routage), soit un protocole de routage dynamique tournant sur le tunnel réannonce par inadvertance la propre route de la destination à travers lui.
SOLUTIONConfirmez avec display ip routing-table que l'interface de sortie de la route de destination est la bonne interface physique ou logique, pas le tunnel ; si nécessaire, fixez-la avec une route statique /32 de priorité supérieure.
SYMPTÔMEUne extrémité déclare le tunnel down ; l'autre extrémité ne montre aucun problème.
CAUSELe Keepalive GRE ne surveille que la direction pour laquelle il est configuré — le Keepalive de ce côté n'exige ni ne reflète rien sur l'état de Keepalive propre au pair, si bien qu'une configuration unilatérale produit un symptôme unilatéral et déroutant.
SOLUTIONActivez le Keepalive avec la même période/nombre de tentatives aux deux extrémités si vous voulez surveiller les deux directions, et lisez display keepalive packets count sur chaque extrémité séparément plutôt que de supposer que la vue d'une extrémité décrit toute la situation.
SYMPTÔMEL'interface de tunnel elle-même signale Up et le Keepalive est sain, mais le trafic réel — surtout TCP — se dégrade ou se bloque par intermittence à mesure que la taille des paquets augmente.
CAUSELa surcharge d'encapsulation propre au GRE fait chuter la taille de charge utile effective sous le MTU de l'interface physique ; quand le MTU de tunnel configuré (et tcp adjust-mss) ne tiennent pas compte de cette surcharge, les paquets plus grands sont silencieusement fragmentés, rejetés, ou disparaissent dans un trou noir selon le chemin, et rien de tout cela n'apparaît comme un événement de tunnel down.
SOLUTIONExécutez le test de balayage de taille ping -s / -a pour trouver le point de rupture réel, puis réglez le mtu du tunnel et le tcp adjust-mss de l'interface sur des valeurs laissant de la marge pour la surcharge du GRE.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Oui — cela s'applique au trafic acheminé via le tunnel. Tout paquet plus grand que le MTU de tunnel configuré est fragmenté avant d'être encapsulé, c'est donc exactement la valeur à ajuster une fois que le test de taille de ping a trouvé votre point de rupture réel.
L'interface Tunnel de Cisco est déjà par défaut en encapsulation GRE, donc tunnel-protocol n'est généralement pas l'incohérence en cause. Ce qui piège les gens : la période de Keepalive minimale configurable chez Cisco est typiquement de 10 secondes, plus élevée que le défaut de 5 secondes de cette plateforme — réglez explicitement les deux extrémités sur la même valeur plutôt que de laisser les défauts en place, et rappelez-vous que le support du Keepalive chez le pair n'a aucune incidence sur le fonctionnement du Keepalive de votre propre côté.
Sur du matériel Cisco plus ancien, le trafic de l'interface Tunnel peut être acheminé par le CPU plutôt que par le matériel ; sous forte charge, le processus CPU qui le gère (visible dans show processes cpu comme un processus consommant une part disproportionnée) peut affamer les paquets Keepalive eux-mêmes, et les Keepalive manqués font tomber le tunnel. Retirer le Keepalive des deux côtés comme étape de diagnostic — pas comme correction permanente — confirmera cela : si le tunnel reste stable Keepalive désactivé, le volume de trafic, et non une vraie panne de liaison, était la cause.
Cette note porte entièrement sur l'échec de l'interface de tunnel elle-même à atteindre Up — protocole, adressage, clé, route et keepalive. Un tunnel qui signale Up mais ne laisse pas correctement passer le ping est un problème en aval — généralement une incohérence de routage ou de détail d'encapsulation sur un tunnel qui existe déjà techniquement — et c'est un tout autre chemin de diagnostic, couvert dans notre note complémentaire sur un tunnel VPN actif mais dont le ping échoue.
C'est presque toujours le cas MTU/fragmentation, pas un problème de route ou de Keepalive — les petits paquets de contrôle et le trafic de test à faible volume traversent bien le tunnel tandis que le trafic réel plus important heurte la surcharge d'encapsulation du GRE et commence à se fragmenter ou à se perdre. Exécutez le test de balayage de taille de ping dans des conditions se rapprochant de la taille du trafic réel, pas juste un ping de taille par défaut.
En pratique, n'importe lequel — GRE est agnostique du protocole au niveau du tunnel, donc OSPF, IS-IS, BGP et RIP fonctionnent tous sur une interface de tunnel GRE exactement comme ils le feraient sur une interface physique, tout comme les protocoles multicast courants. Le tunnel lui-même ne comprend ni ne filtre ce qu'il contient.
Cette note s'appuie sur le modèle de classification des pannes GRE du routeur Huawei série AR et ses commandes display this / display ip routing-table / display keepalive packets count, ainsi que sur les cas de terrain et notes multi-fournisseurs qui les sous-tendent. Si votre appareil est d'un autre fournisseur, les commandes exactes changent, mais la liste de contrôle sous-jacente — mode de protocole, adressage, clé, route, direction du keepalive, MTU — s'applique directement. Elle ne couvre pas en profondeur le GRE tournant à l'intérieur d'un tunnel IPSec, ni les limites de performance du transfert multicast sur GRE.
Dites-nous laquelle des sept vérifications — protocole, adresse, clé, route, keepalive, ou MTU — vous avez déjà écartée, plus votre sortie de display this, et nous vous aiderons à interpréter le reste.