Un Spoke qui n'apparaît jamais dans la table de pairs NHRP du Hub ressemble à un seul problème, mais le manuel de maintenance de Huawei le traite comme cinq ou six candidats cachés derrière le même symptôme. Voici le flux d'enregistrement lui-même, les commandes display et debug pour chaque point de contrôle, et les noms exacts des champs dans les compteurs qui indiquent lequel c'est réellement.
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
DSVPN comporte quatre grandes catégories de pannes dans le manuel de maintenance de Huawei lui-même — cette note traite en profondeur la première, l'enregistrement spoke-vers-hub.
Le manuel de maintenance de la série AR de Huawei regroupe les pannes DSVPN en quatre symptômes larges : l'échec d'enregistrement du Spoke auprès du Hub, l'inaccessibilité Spoke-à-Spoke en mode non-shortcut, l'inaccessibilité Spoke-à-Spoke en mode shortcut, et NHRP qui tombe après avoir été précédemment établi. Cette note porte entièrement sur la première catégorie — l'échec d'enregistrement — car c'est à la fois le point d'entrée le plus courant et celui que toutes les autres catégories supposent déjà résolu.
Voici ce qui suit : le flux d'enregistrement paquet par paquet avec une sortie debug réelle, l'ordre de diagnostic que suit l'organigramme officiel de Huawei, six pièges de terrain, et une FAQ tirée de la propre section FAQ DSVPN de Huawei.
Quatre paquets, dans l'ordre : la requête d'enregistrement du Spoke, sa réception par le Hub, la réponse du Hub, et la réception de cette réponse par le Spoke. La sortie debug ci-dessous est réelle, tirée de la propre référence de débogage terrain de Huawei.
Les libellés du schéma et les noms de champs debug restent en anglais pour la clarté technique.
PacketType 3 est une requête d'enregistrement, PacketType 4 est une réponse d'enregistrement. SrcNbmaAddr et SrcProtAddr identifient les adresses publique et de tunnel du Spoke ; DstProtAddr est l'adresse de tunnel du Hub ; Request ID relie la requête à sa réponse correspondante. Si le debug du Spoke lui-même montre qu'il a envoyé la requête et reçu ensuite une réponse correspondante, mais qu'aucune entrée de pair NHRP n'apparaît jamais — c'est le seul cas où le propre guide de Huawei recommande d'escalader directement vers le développement NHRP, car toutes les causes de configuration documentées ont déjà été écartées.
<Huawei>terminal monitor
<Huawei>terminal debugging
<Huawei>debugging timeout 0
<Huawei>debugging nhrp all
// turn off when done:
<Huawei>undo debugging all
<Huawei>undo terminal monitor
<Huawei>undo terminal debuggingSpoke sends the registration packet:
[NhrpPeerMng-Register] Send Nhrp packet info: PacketSize = 92, PacketType = 3,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3695974589.
Hub receives the registration packet:
[NhrpPeerMng-Register] Recv Nhrp packet info: PacketSize = 92, PacketType = 3,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3630044566.
Hub replies to the registration:
[NhrpPeerMng-Register] Send Nhrp packet info: PacketSize = 112, PacketType = 4,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3630044566.
Spoke receives the Hub's reply:
[NhrpPeerMng-Register] Recv Nhrp packet info: PacketSize = 112, PacketType = 4,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3695974589.
// if the Spoke received the reply but the NHRP peer entry still never forms,
// escalate to NHRP development -- every configuration-level cause is ruled outVoici l'organigramme officiel de Huawei pour l'échec d'enregistrement spoke-vers-hub, dans l'ordre — chaque étape élimine une couche avant de passer à la suivante.
<Spoke> interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo ipsec profile
[Spoke-Tunnel0/0/0] quit
<Spoke> display ip routing-table
<Hub> display ip routing-table
// confirm each side has a route to the other's NBMA address
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
// if state is down: undo shutdown
<Hub> display this
<Spoke> display this
// compare nhrp authentication and gre key line by line
<Hub> display nhrp peer
<Hub> reset nhrp statistics interface Tunnel 0/0/0
<Spoke> reset nhrp statistics interface Tunnel 0/0/0
// trigger a fresh registration from the Spoke, then:
<Spoke> display nhrp statistics interface Tunnel 0/0/0
// check RegisterRequestSendSuccess and RegisterReplyCorrectRecv
[Spoke-Tunnel0/0/0] ipsec profile ipsec1
<Spoke> display ipsec saChacune de ces causes provient directement des sections de traitement des pannes DSVPN et de la FAQ de Huawei — rien ici n'est inventé.
SYMPTÔMEL'accessibilité NBMA est confirmée bonne, l'interface Tunnel est up des deux côtés, et le Spoke ne s'enregistre toujours jamais — sans aucun message d'erreur indiquant pourquoi.
CAUSEC'est l'une des causes racines courantes que le manuel de Huawei lui-même liste pour l'échec d'enregistrement : la clé GRE configurée sur l'interface tunnel du Spoke ne correspond pas à celle du Hub. Comme la vérification de la clé GRE se fait silencieusement au niveau de l'encapsulation du tunnel, rien dans les journaux au niveau NHRP ne la désigne directement.
CORRECTIONComparez la valeur gre key sur les interfaces tunnel du Hub et du Spoke avec display this, et alignez-les avec la commande gre key. Faites-le avant de passer du temps sur les compteurs spécifiques à NHRP — c'est une vérification d'une ligne qui écarte toute une catégorie de pannes.
SYMPTÔMELe même tableau que le cas de la clé GRE — le routage est bon, le tunnel est up, l'enregistrement ne se termine tout simplement jamais.
CAUSELe manuel de Huawei liste ceci comme une cause distincte à part entière : le Hub a une chaîne d'authentification NHRP configurée mais pas le Spoke, ou les deux côtés ont configuré des chaînes différentes. Dans les deux cas, l'effet est identique à une incompatibilité de clé GRE vue de l'extérieur — échec silencieux de l'enregistrement sans erreur évidente.
CORRECTIONComparez nhrp authentication des deux côtés via display this sous l'interface tunnel/MGRE, et alignez-les avec la commande nhrp authentication. Vérifiez ceci en même temps que la clé GRE — ce sont toutes deux des vérifications de cohérence de configuration à la même étape.
SYMPTÔMELe Spoke envoie sa requête de résolution/enregistrement avec succès et le Hub génère même un candidat d'entrée de pair, mais la table de pairs NHRP sur le Hub ne se complète jamais réellement pour ce Spoke.
CAUSEIl s'agit d'une véritable panne que le manuel de Huawei documente directement : lorsque le protocole de sécurité IPSec utilise SHA-2, et que les deux extrémités du tunnel n'ont ipsec authentication sha2 compatible configuré que d'un seul côté, l'enregistrement échoue. Cela compte surtout entre différents constructeurs ou différentes versions de produits, où les détails d'implémentation SHA-2 peuvent différer suffisamment pour nécessiter le drapeau de compatibilité des deux côtés.
CORRECTIONVérifiez si ipsec authentication sha2 compatible enable est configuré des deux côtés chaque fois que la proposition IPSec utilise SHA-2 — pas seulement d'un côté. Exécutez display ipsec sa pour confirmer que la SA se forme réellement une fois les deux côtés alignés.
<Hub> ipsec authentication sha2 compatible enable
<Spoke> ipsec authentication sha2 compatible enable
// must be configured on BOTH ends when the IPSec proposal uses SHA-2
<Hub> display ipsec saSYMPTÔMEUn cas réel documenté : DSVPN over IPSec, le Hub utilise des interfaces Tunnel distinctes par Spoke, et la négociation IKE échoue carrément — display ike sa sur le Hub montre la SA bloquée en état NEG (négociation) sans jamais atteindre RD (prête).
CAUSELe débogage sur le Hub (debugging ipsec all / debugging ikev1 all) a montré directement la cause réelle : « IKE check ike peer same, the binding ike peer is different » — les deux interfaces Tunnel du Hub utilisaient la même adresse IP source (1.1.1.1) mais pointaient vers des profils IPSec différents, donc IKE ne pouvait pas résoudre quelle identité de pair s'appliquait à la négociation de quel Spoke.
CORRECTIONConfigurez une ike identity par Spoke (basée sur fqdn, cela fonctionne bien), référencez-la dans le profil ipsec de chaque Tunnel avec match ike-identity, et configurez une gre key distincte par interface Tunnel pour garder le trafic NHRP isolé entre elles. L'ike peer de chaque Spoke utilise ensuite local-id-type fqdn avec un local-id correspondant.
<Hub> terminal debugging
<Hub> terminal monitor
<Hub> debugging ipsec all
<Hub> debugging ikev1 all
IKE/7/IKE_Debug Info:5:2607 IKE check ike peer same, get ike peer name (peer-name = ipsec1, ifindex = 18).
IKE/3/IKE_Debug Error:5:2628 IKE check ike peer same, the binding ike peer is different(ifindex = 27, peer name = ipsec3).
[Hub] interface Tunnel0/0/0
[Hub-Tunnel0/0/0] ip address 10.17.1.1 255.255.255.0
[Hub-Tunnel0/0/0] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/0] source vpn-instance test 1.1.1.1
[Hub-Tunnel0/0/0] ipsec profile ipsec1
[Hub-Tunnel0/0/0] gre key cipher AAA
[Hub-Tunnel0/0/0] quit
[Hub] interface Tunnel0/0/100
[Hub-Tunnel0/0/100] ip address 100.17.1.1 255.255.255.0
[Hub-Tunnel0/0/100] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/100] source vpn-instance test 1.1.1.1
[Hub-Tunnel0/0/100] ipsec profile ipsec2
[Hub-Tunnel0/0/100] gre key cipher BBB
[Hub-Tunnel0/0/100] quit
[Hub] ike identity i1
[Hub-ike-identity-i1] fqdn spoke1
[Hub] ipsec profile ipsec1
[Hub-ipsec-profile-ipsec1] ike-peer ipsec1
[Hub-ipsec-profile-ipsec1] match ike-identity i1
<Spoke1> ike peer ipsec1
[Spoke1-ike-peer-ipsec1] local-id-type fqdn
[Spoke1-ike-peer-ipsec1] local-id spoke1SYMPTÔMEChaque paramètre de configuration est correct — clé GRE, authentification NHRP, profil IPSec — et le Spoke ne s'enregistre toujours pas.
CAUSEL'interface Tunnel elle-même est désactivée administrativement d'un côté — une étape facile à sauter car les ingénieurs supposent que si le tunnel était down, autre chose serait aussi manifestement en défaut. C'est précisément pour cette raison qu'elle figure comme étape 3 dans le propre flux de diagnostic de Huawei.
CORRECTIONExécutez display interface interface-type interface-number sur le Hub et le Spoke et vérifiez l'état réel, pas seulement des suppositions basées sur des symptômes de couche supérieure. undo shutdown si c'est down. Faites-le tôt — c'est l'étape 3 dans l'ordre de diagnostic ci-dessus, avant les vérifications de cohérence de configuration.
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo shutdownSYMPTÔMEPas exactement un échec d'enregistrement — l'enregistrement finit par réussir, mais notablement lentement après un changement d'adresse source du Spoke, ou après un rebond de l'interface Tunnel.
CAUSEPar défaut, un Spoke se réenregistre auprès du Hub toutes les 1800 secondes, et le holdtime d'une entrée de pair NHRP est également de 1800 secondes par défaut. Les deux sont délibérément conservateurs, mais cela signifie qu'après un événement déclencheur — comme un shutdown/undo shutdown du Tunnel, ou un changement d'adresse publique du Spoke — l'entrée périmée ne s'efface pas et la nouvelle ne s'établit pas avant que ces valeurs par défaut ne se soient écoulées, à moins que quelque chose ne force les choses plus tôt.
CORRECTIONConfigurez nhrp registration no-unique sur le Spoke pour qu'il indique explicitement au Hub d'écraser une entrée de pair NHRP conflictuelle au lieu d'attendre qu'elle expire. Ajustez nhrp entry holdtime seconds et l'intervalle de réenregistrement à la baisse si votre environnement change d'adresses source assez souvent pour que les valeurs par défaut causent un délai notable.
<Spoke> nhrp registration no-unique
<Spoke> nhrp entry holdtime 7200
// defaults: 1800s re-registration interval, 1800s NHRP peer holdtimeTiré directement de la propre section FAQ DSVPN de Huawei.
L'activation de la licence. Exécutez display license accept agreement et display license state — certains modèles de routeur AR nécessitent une licence DSVPN achetée, et si elle n'est pas active, display nhrp peer all signalera la licence comme désactivée au lieu d'afficher des entrées de pair, peu importe à quel point le reste de la configuration est correct.
<Huawei> display license accept agreement
Active license Accept Agreement: yes
Item name : LAR0DSVPN04
Item type : Function
Item state : Disable, -
Item left time :-
Item used time :-
Description : DSVPN Function Controller
<Huawei> display license state
Info: No license actived on master board.
<Huawei> display nhrp peer all
Info: DSVPN or SECE License is disable, please check availability of the license
and load new license.
Number of nhrp peers: 0Dans l'ordre : état de la licence, accessibilité de route de l'interface source, si l'extrémité distante a réellement reçu le paquet, cohérence de la clé GRE et de l'authentification NHRP, compatibilité IPSec/SHA-2 si IPSec est superposé, si une autre interface Tunnel sur le même boîtier référence la même source (nécessite l'isolation par gre key), et le NAT au Hub s'il y en a un (le Spoke doit s'enregistrer à l'adresse post-NAT du Hub).
Remettez les compteurs à zéro et vérifiez display nhrp statistics interface après avoir déclenché un nouvel enregistrement. Si RegisterRequestSendSuccess n'affiche aucun compte, le Spoke ne fait même pas sortir la requête — vérifiez d'abord l'interface locale et la route. Si RegisterRequestSendSuccess a un compte mais pas RegisterReplyCorrectRecv, la requête est bien partie mais aucune réponse valide n'est revenue — vérifiez la configuration du Hub et le chemin de retour.
Parce que l'ancienne entrée de pair NHRP du Hub pour ce Spoke n'est pas écrasée immédiatement par défaut — elle expire selon son propre minuteur holdtime, qui est de 1800 secondes sauf réglage. Configurez nhrp registration no-unique sur le Spoke pour qu'il indique explicitement au Hub d'écraser l'entrée conflictuelle au lieu d'attendre.
Non — c'est une catégorie de panne différente dans le manuel de Huawei lui-même (inaccessibilité Spoke-à-Spoke en mode non-shortcut ou shortcut, selon votre mode DSVPN), et elle suppose que l'enregistrement a déjà réussi, ce qui est exactement ce que couvre cette note. Cela mérite son propre article séparé.
Cette note s'articule entièrement autour de l'échec d'enregistrement spoke-vers-hub, en utilisant le déroulé de diagnostic réel, la sortie debug réelle et de vrais cas de panne tirés du propre manuel de maintenance de la série AR de Huawei. Elle ne couvre pas l'inaccessibilité Spoke-à-Spoke en mode non-shortcut ou shortcut, ni NHRP qui tombe après avoir été précédemment établi — ce sont des catégories de panne distinctes dans le même manuel, chacune méritant sa propre note.
Envoyez-nous les compteurs RegisterRequestSendSuccess / RegisterReplyCorrectRecv et la sortie display nhrp peer des deux côtés — nous vous aiderons à l'interpréter.