A Spoke that never shows up in the Hub's NHRP peer table looks like one problem, but Huawei's own maintenance handbook treats it as five or six candidates hiding behind the same symptom. Here's the registration flow itself, the display and debug commands for each checkpoint, and the exact field names in the counters that tell you which one it actually is.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
DSVPN has four broad failure categories in Huawei's own maintenance handbook — this note is about the first one, spoke-to-hub registration, in full depth.
Huawei's own AR-series maintenance handbook groups DSVPN faults into four broad symptoms: the Spoke failing to register with the Hub, non-shortcut Spoke-to-Spoke unreachability, shortcut Spoke-to-Spoke unreachability, and NHRP going down after it was previously established. This note is entirely about the first category — registration failure — because it's both the most common entry point and the one every other category assumes has already succeeded.
What follows: the registration flow packet by packet with real debug output, the diagnostic order Huawei's own flowchart follows, six field gotchas, and an FAQ pulled from Huawei's own DSVPN FAQ section.
Four packets, in order: the Spoke's registration request, the Hub receiving it, the Hub's reply, and the Spoke receiving that reply. The debug output below is real, from Huawei's own field debugging reference.
Diagram labels and debug field names are kept in English for engineering clarity.
PacketType 3 is a Register Request, PacketType 4 is a Register Reply. SrcNbmaAddr and SrcProtAddr identify the Spoke's public and tunnel addresses; DstProtAddr is the Hub's tunnel address; Request ID ties the request to its matching reply. If the Spoke's own debug shows it sent the request and later received a matching reply, but no NHRP peer entry ever appears — that's the one case Huawei's own guide says to escalate straight to NHRP development, because every documented configuration cause has already been ruled out.
<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 outThis is Huawei's own flowchart for spoke-to-hub registration failure, in order — each step rules out one layer before moving to the next.
<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 saEvery one of these comes straight from Huawei's own DSVPN fault-handling and FAQ sections — nothing here is invented.
SYMPTOMNBMA reachability is confirmed good, the Tunnel interface is up on both ends, and the Spoke still never registers — with no error message pointing at why.
CAUSEThis is one of the common root causes Huawei's own handbook lists for registration failure: the GRE key configured on the Spoke's tunnel interface doesn't match the Hub's. Because the GRE key check happens silently at the tunnel encapsulation layer, there's nothing in the NHRP-level logs that names it directly.
FIXCompare the gre key value on both Hub and Spoke tunnel interfaces with display this, and align them with the gre key command. Do this before spending time on NHRP-specific counters — it's a one-line check that rules out an entire fault category.
SYMPTOMSame picture as the GRE key case — routing is fine, tunnel is up, registration just never completes.
CAUSEHuawei's handbook lists this as its own distinct cause: the Hub has an NHRP authentication string configured but the Spoke doesn't, or the two sides configured different strings. Either way the effect is identical to a GRE key mismatch from the outside — silent registration failure with no obvious error.
FIXCompare nhrp authentication on both ends via display this under the tunnel/MGRE interface, and align them with the nhrp authentication command. Check this alongside the GRE key in the same pass — they're both config-consistency checks at the same step.
SYMPTOMThe Spoke sends its resolution/registration request successfully and the Hub even generates a peer entry candidate, but the NHRP Peer table on the Hub still never actually completes for that Spoke.
CAUSEThis is a real fault Huawei's own handbook documents directly: when the IPSec security protocol uses SHA-2, and the tunnel's two ends are configured with ipsec authentication sha2 compatible only on one side, registration fails. This matters most between different vendors or different product versions, where SHA-2 implementation details can differ enough to need the compatibility flag on both ends.
FIXCheck whether ipsec authentication sha2 compatible enable is configured on both ends whenever the IPSec proposal uses SHA-2 — not just one. Run display ipsec sa to confirm the SA actually forms once both sides match.
<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 saSYMPTOMA real documented case: DSVPN over IPSec, Hub uses separate Tunnel interfaces per Spoke, and IKE negotiation fails outright — display ike sa on the Hub shows the SA stuck in NEG (negotiating) state and never reaching RD (ready).
CAUSEDebug on the Hub (debugging ipsec all / debugging ikev1 all) showed the actual cause directly: "IKE check ike peer same, the binding ike peer is different" — the Hub's two Tunnel interfaces used the identical source IP address (1.1.1.1) but pointed at different IPSec profiles, so IKE couldn't resolve which peer identity applied to which Spoke's negotiation.
FIXConfigure an ike identity per Spoke (fqdn-based works well), reference it in each Tunnel's ipsec profile with match ike-identity, and configure a distinct gre key per Tunnel interface to keep NHRP traffic isolated between them. Each Spoke's ike peer then uses local-id-type fqdn with a matching local-id.
<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 spoke1SYMPTOMEvery configuration parameter checks out — GRE key, NHRP authentication, IPSec profile — and the Spoke still doesn't register.
CAUSEThe Tunnel interface itself is administratively shut down on one end — a step that's easy to skip because engineers assume that if the tunnel were down, something else would obviously be wrong too. It's specifically listed as step 3 in Huawei's own diagnostic flow for exactly this reason.
FIXRun display interface interface-type interface-number on both Hub and Spoke and check the actual state, not just assumptions from higher-layer symptoms. undo shutdown if it's down. Do this early — it's step 3 in the diagnostic order above, before config-consistency checks.
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo shutdownSYMPTOMNot a registration failure exactly — registration eventually succeeds, but noticeably slowly after a Spoke's source address changes, or after a Tunnel interface bounce.
CAUSEBy default, a Spoke re-registers with the Hub every 1800 seconds, and an NHRP peer entry's holdtime is also 1800 seconds by default. Both are deliberately conservative, but they mean that after a triggering event — like a Tunnel shutdown/undo shutdown, or the Spoke's public address changing — the stale entry doesn't clear and the new one doesn't establish until those defaults finish playing out, unless something forces it sooner.
FIXConfigure nhrp registration no-unique on the Spoke so it explicitly tells the Hub to overwrite a conflicting NHRP peer entry instead of waiting for it to age out. Tune nhrp entry holdtime seconds and the re-registration interval down if your environment changes source addresses often enough that the defaults cause noticeable delay.
<Spoke> nhrp registration no-unique
<Spoke> nhrp entry holdtime 7200
// defaults: 1800s re-registration interval, 1800s NHRP peer holdtimePulled directly from Huawei's own DSVPN FAQ section.
License activation. Run display license accept agreement and display license state — some AR router models require a purchased DSVPN license, and if it isn't active, display nhrp peer all will report the license as disabled instead of showing peer entries, no matter how correct the rest of the configuration is.
<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: 0In order: license status, source-interface route reachability, whether the far end actually received the packet at all, GRE key and NHRP authentication consistency, IPSec/SHA-2 compatibility if IPSec is layered on top, whether another Tunnel interface on the same box is referencing the same source (needs gre key isolation), and NAT at the Hub if one is present (the Spoke must register to the Hub's post-NAT address).
Zero the counters and check display nhrp statistics interface after triggering a fresh registration. If RegisterRequestSendSuccess shows no count, the Spoke isn't even getting the request out — check the local interface and route first. If RegisterRequestSendSuccess has a count but RegisterReplyCorrectRecv doesn't, the request left fine but no valid reply came back — check the Hub's config and the return path.
Because the Hub's old NHRP peer entry for that Spoke doesn't get overwritten immediately by default — it ages out on its own holdtime timer, which is 1800 seconds unless tuned. Configure nhrp registration no-unique on the Spoke so it explicitly tells the Hub to overwrite the conflicting entry instead of waiting.
No — that's a different fault category in Huawei's own handbook (non-shortcut or shortcut Spoke-to-Spoke unreachability, depending on your DSVPN mode), and it assumes registration has already succeeded, which is exactly what this note covers. It deserves its own separate walkthrough.
This note is built entirely around spoke-to-hub registration failure, using the actual diagnostic flow, real debug output and real fault cases from Huawei's own AR-series maintenance handbook. It doesn't cover non-shortcut or shortcut Spoke-to-Spoke unreachability, or NHRP going down after previously being established — those are separate fault categories in the same handbook, each worth its own note.
Send us the RegisterRequestSendSuccess / RegisterReplyCorrectRecv counters and the display nhrp peer output from both ends — we'll help you read it.