Le contrôleur affiche une liaison de site à site en gris, sans débit ni données de performance entre deux sites, et l'appareil lui-même ne montre aucune connexion EVPN. Voici la liste de contrôle en couches qui trouve la panne le plus vite — TNP, puis DTLS, puis la route SD-WAN — avec les commandes display exactes pour chaque couche, plus ce qu'il faut vérifier une fois qu'une connexion s'est bien formée mais que son état ne passe toujours pas à UP.
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
Une liaison grise sur le contrôleur signifie simplement que deux sites n'échangent pas encore de données — cela n'indique pas lequel de plusieurs problèmes d'underlay complètement différents en est la cause réelle.
Une connexion EVPN entre deux sites SD-WAN dépend de deux choses qui doivent exister avant même de pouvoir se former : les deux sites doivent avoir appris le TNP (Tunnel Network Point) l'un de l'autre, ce qui dépend lui-même de l'établissement du DTLS entre le CPE et le RR, et les deux sites doivent avoir appris une route l'un vers l'autre — spécifiquement une route SD-WAN, pas n'importe quel chemin joignable. Vérifier cela dans l'ordre — TNP, puis DTLS, puis la route — trouve la couche réellement cassée bien plus vite que de se lancer directement dans une capture de paquets.
Voici l'ordre de diagnostic sur lequel ce texte s'appuie, tiré du propre modèle de classification des pannes SD-WAN/EVPN du routeur Huawei AR, les vérifications et commandes pour chaque couche, ce qu'il faut regarder une fois qu'une connexion s'est bien formée mais que son état n'est toujours pas UP, et une série de réponses de FAQ tirées de la même documentation de maintenance. Pour la logique de tunnel IPSec/GRE sous un VPN de succursale plus conventionnel plutôt que du SD-WAN, voir « Le tunnel VPN IPSec ne monte pas ? » et « Le tunnel VPN est actif mais le Ping échoue ».
Les pannes de liaison SD-WAN se répartissent en deux formes sur le contrôleur : aucune connexion EVPN n'existe entre deux sites, ou une connexion existe mais son état ne passe pas à UP.
Placer d'abord le symptôme sur cet arbre indique si l'on dépanne TNP/DTLS/routage, ou un problème plus étroit de perçage NAT ou de Keepalive sur une connexion qui existe déjà.
Les légendes du schéma restent en anglais pour la clarté technique.
La branche de gauche est ce qu'il faut parcourir lorsque la connexion n'existe pas du tout — couche par couche, TNP en premier. La branche de droite est une question plus étroite sur une connexion déjà formée mais qui n'arrive pas à finir de monter, et elle pointe généralement vers le chemin NAT ou le Keepalive, pas vers TNP ou la route.
Cinq couches, chacune avec sa propre commande display — l'arbre de panne ci-dessus indique par laquelle commencer.
Si le TNP n'est pas UP, le DTLS n'est même jamais déclenché sur cette liaison — commencez ici avant toute chose.
<Huawei> display site-tnp 29 verbose
// V300 -- confirms whether the TNP's underlying interface protocol is Up;
// with NAT traversal off, TNP state depends only on interface protocol state
<Huawei> display evpn site-tnp 29 verbose
// V600 equivalent
<Huawei> tracert -p 3478
// checks whether the path blocks the NAT probe portLe TNP CPE-vers-RR est appris via DTLS, donc si le TNP ne monte pas et que la traversée NAT n'est pas en cause, le DTLS est la couche suivante à vérifier.
<Huawei> display dtls peer-connection status
// V300 -- CLOSE = established; INIT / REGISTERING = not established
<Huawei> display dtls client connection
// V600 equivalent
<Huawei> tracert -p 55100
// DTLS uses port 55100 -- check whether a firewall in the path is blocking itL'EVPN a besoin de deux choses pour se former : le TNP du site de destination, et une route vers ce site qui soit spécifiquement une route SD-WAN — pas n'importe quel chemin joignable.
<Huawei> display smart-policy-route spr-index-table all
// V300 only -- confirms whether an SD-WAN route to the destination site exists
<Huawei> display saved-configuration
// Tunnel / BGP entries present here after a reboot = save was executed on an
// SD-WAN device that should never have allowed it (R19C00) -- factory-reset and re-onboardLe TNP, le DTLS et la route sont tous corrects, mais la connexion ne se forme toujours pas — voici ce qu'il reste.
<Huawei> display evpn connection verbose
// current connection count vs. spec -- Full-Mesh + a low-end model can exceed it
<Huawei> display site-tnp 29 verbose
// Current Conn Ref Count = 0 -> this end has no business route from the peer site
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 received-routes
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 advertised-routes
// received-routes on the branch/RR, advertised-routes on the RR -- confirms
// whether the business route was actually reflected onwardUne question plus étroite : display evpn connection montre désormais quelque chose, mais son état ne passe pas à UP.
<Huawei> display connection 12345
// V300 -- ConnStatus: Invalid / Init / NatParse / CheckConn / Pending / Active
// stuck at NatParse specifically = NAT hole punching failed
<Huawei> display evpn connection 12345 verbose
// V600 equivalent; SourcePublicPort / DestPublicPort -- compare both ends
// for an asymmetric NAT translating the two directions inconsistently
<Huawei> display fe slot 0 fe-id 0 table connect-encap 12345
// SEND_KA_CNT / RECV_KA_COUNT -- send-without-receive on one side points at
// the network in between, not the CPEUne fois que les couches ci-dessus ont indiqué où se situe le problème, ces six causes expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEL'état du TNP ne passe pas à UP sur une liaison spécifique, même si l'interface elle-même est active.
CAUSEAvec la traversée NAT désactivée, l'état du TNP ne suit que l'état de protocole propre de l'interface — donc activer la traversée NAT sur une liaison qui n'a en réalité pas de NAT déclenche une sonde qui n'a aucune raison de réussir proprement, et la laisser désactivée sur une liaison qui a du NAT saute une sonde dont la liaison a réellement besoin. L'un ou l'autre décalage empêche le TNP de confirmer UP.
SOLUTIONFaites correspondre le réglage de la traversée NAT à ce qui existe réellement sur le chemin WAN, liaison par liaison, dans la vue de liaison WAN du contrôleur — pas un réglage uniforme appliqué à tous les sites.
SYMPTÔMEDeux sites RR, aucun derrière du NAT, n'arrivent toujours pas à faire passer leur connexion EVPN à UP.
CAUSEC'est un cas réel documenté — les deux sites RR avaient des adresses Public configurées manuellement, et les valeurs étaient inversées : l'adresse Public de RR1 était réglée sur l'adresse d'interface de RR2, et celle de RR2 sur celle de RR1. L'adresse semblait plausible sur chaque appareil pris individuellement, ce qui explique exactement pourquoi une revue de configuration ne l'a pas détecté.
SOLUTIONConfirmez qu'aucun des deux sites RR n'a réellement besoin d'une adresse Public configurée manuellement (l'absence de NAT sur le chemin signifie généralement qu'elle ne devrait pas être définie) ; si l'une est requise, vérifiez-la par rapport à l'adresse d'interface réelle du pair plutôt que de supposer qu'elle a été copiée correctement.
SYMPTÔMEDans un réseau SD-WAN Full-Mesh, un site — généralement le modèle bas de gamme — peut joindre certains sites mais pas d'autres, sans panne évidente par liaison.
CAUSEFull-Mesh signifie que chaque site essaie de construire une connexion EVPN vers tous les autres sites du réseau ; un modèle d'appareil porte une spécification stricte de nombre de connexions, et un CPE bas de gamme dans un grand déploiement Full-Mesh peut tout simplement manquer de place avant que tous les sites soient connectés.
SOLUTIONVérifiez display evpn connection verbose par rapport au nombre de connexions nominal du modèle ; si le nombre de sites a dépassé ce que le matériel déployé prend en charge, redimensionnez le modèle du site ou faites passer ce site par un RR/Hub plutôt que d'attendre un maillage complet.
SYMPTÔMELa machine à états de connexion de deux sites succursales reste indéfiniment à NatParse ; l'underlay est joignable et le port 4500 est ouvert.
CAUSEDeux combinaisons de NAT spécifiques ne parviennent jamais à percer avec succès, quelle que soit la façon dont le reste du réseau est configuré : une extrémité derrière un NAT Port Restricted Cone avec l'autre derrière un NAT Symmetric, ou les deux extrémités derrière un NAT Symmetric.
SOLUTIONCe n'est pas une correction de configuration, c'est une contrainte de conception réseau. Confirmez le type de NAT sur l'équipement de bordure de chaque site, et là où la combinaison n'est pas prise en charge, faites transiter le trafic de cette paire par un RR/Hub plutôt que d'attendre une connexion directe site à site.
SYMPTÔMEL'état de la connexion EVPN oscille Up/Down de façon répétée sans rien de visiblement anormal sur l'underlay, la bande passante, le CPU ou le duplex de la liaison.
CAUSEUn cas réel documenté : le TNP d'un côté fait toujours référence à un TNP pair que l'autre côté a déjà remplacé — l'extrémité distante montre deux de ses propres TNP connectés au TNP unique de l'extrémité proche, tandis que l'extrémité proche ne montre que ce seul TNP connecté en retour. La référence obsolète déclenche continuellement une renégociation.
SOLUTIONreset connection site-tnp sur V300, ou reset evpn site-tnp sur V600, efface le résidu et permet aux deux côtés de réapprendre une relation TNP cohérente.
SYMPTÔMEDans un déploiement à double passerelle, les deux CPE ne sont pas d'accord sur l'état de la liaison — l'un montre sa liaison locale active tandis que le pair montre la liaison étendue correspondante Down, ou l'inverse.
CAUSEL'Interlink entre les deux CPE à double passerelle est censé synchroniser l'état de liaison entre eux ; si display ms-channel montre Connected sur un CPE et Disconnected sur l'autre pour le même Interlink, la liaison fonctionne dans un seul sens — les messages de synchronisation ne passent que dans une direction.
SOLUTIONConfirmez le décalage avec display ms-channel sur les deux CPE, puis vérifiez les compteurs de pulsation avec deux appels display ms-channel-static espacés de cinq secondes — TX augmentant mais pas RX (ou l'inverse) réduit le problème à une connexion physique ou un câblage sur l'Interlink lui-même, pas la configuration SD-WAN.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Vérifiez d'abord l'état du TNP (display site-tnp / display evpn site-tnp verbose) — s'il n'est pas UP, rien au-delà de ce point n'a d'importance pour l'instant. Si le TNP est UP, vérifiez ensuite le DTLS (CLOSE signifie établi). Si le DTLS va bien, vérifiez une route vers le site de destination spécifiquement en tant que route SD-WAN (display smart-policy-route spr-index-table all sur V300). Ce n'est qu'une fois ces trois éléments vérifiés qu'il est pertinent de regarder le nombre de connexions, une mauvaise configuration NAT/adresse, ou une liaison unilatérale.
Oui — l'existence même d'une connexion signifie que le TNP et la route SD-WAN vont déjà bien des deux côtés. Ce qui reste, c'est la joignabilité de l'underlay, si les deux côtés ont réellement construit la connexion (comparez display evpn connection site-id de chaque côté), le perçage NAT (ConnStatus bloqué à NatParse), ou un Keepalive qui ne passe pas dans une direction.
NatParse est l'étape de perçage de la machine à états de connexion (Invalid → Init → NatParse → CheckConn → Pending → Active) ; y rester bloqué pointe vers la joignabilité de l'underlay, le port 4500 bloqué quelque part sur le chemin, un équipement NAT traduisant les deux sens de façon incohérente (comparez SourcePublicPort d'un côté à DestPublicPort de l'autre), ou une combinaison de types de NAT fondamentalement non prise en charge entre les deux extrémités.
Perte de paquets sur l'underlay, un port Interlink à double passerelle Down, une interface WAN bloquée en semi-duplex, un trafic dépassant la bande passante de la liaison, une surcharge CPU sur l'appareil (vérifiez display cpu-usage pour un cœur à 100 %), une gigue de latence de liaison déclenchant un minuteur de détection de panne réglé de façon trop agressive, ou un résidu de TNP où un côté fait référence à un TNP pair que l'autre côté n'a plus.
Comparez d'abord Current Conn Ref Count dans display site-tnp {site-id} verbose des deux côtés ; 0 signifie que ce côté n'a aucune route métier du pair. Vérifiez ensuite display bgp evpn all routing-table peer ip received-routes sur la succursale et le RR, et advertised-routes sur le RR, pour savoir si la route métier a été reçue et réellement réfléchie — une liste blanche de politique de routage côté réception qui ne couvre pas le sous-réseau réel du pair est la cause silencieuse la plus courante.
Pas nécessairement. Un TNP qui est Down sur un CPE n'est jamais synchronisé vers son pair à double passerelle, donc une différence de nombre causée spécifiquement par un TNP Down qui n'est pas reflété est normale et attendue. Cela ne devient un véritable problème que si chaque TNP impliqué montre Up sur les deux CPE et que les nombres restent en désaccord — à ce stade, faire cycler l'interface physique (shutdown / undo shutdown) est l'étape suivante, et si cela ne résout pas le problème, escaladez avec les journaux de display ms-channel-static des deux CPE et une capture debugging connection all.
Cette note s'appuie sur le modèle de classification des pannes SD-WAN EVPN du routeur Huawei série AR/NetEngine AR — le découpage en couches TNP/DTLS/route et les commandes display site-tnp / display evpn connection / display dtls / display ms-channel, ainsi que les cas de terrain qui les sous-tendent, tirés de la même documentation de maintenance couvrant spécifiquement les scénarios SD-WAN. Les noms de commandes diffèrent légèrement entre les jeux de commandes V300 et V600 ; les deux sont donnés côte à côte ci-dessus partout où ils divergent. Elle ne couvre pas intégralement les écrans de configuration côté contrôleur, les pannes de reconnaissance d'application ou de sélection de chemin, ni les diagnostics spécifiques à la perte de paquets qui figurent dans un chapitre séparé de la même documentation source.
Dites-nous à quelle couche ça bloque — TNP, DTLS, ou la route SD-WAN — avec la sortie de display site-tnp / display evpn connection, et nous vous aiderons à l'interpréter.