Two Huawei AR branch routers (Spoke1, Spoke2) and a Cisco router at headquarters (Hub), forming a DSVPN Over IPSec network — dynamic mGRE tunnels, NHRP registration, and per-tunnel IPSec profiles that let the branches talk directly to each other without routing through headquarters.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Plain IPSec tunnels multiply one-per-pair. DSVPN lets every site reach every other site through one dynamic mesh.
A branch-to-headquarters IPSec tunnel like the ones in our other notes works fine for two sites. Add a third branch that also needs to reach the first two, and a static, point-to-point design means configuring and maintaining a separate tunnel for every pair — with headquarters relaying every branch-to-branch packet even when the two branches could reach each other directly. DSVPN (Dynamic Smart VPN) solves this with a Hub-Spoke model built on multipoint GRE (mGRE) and NHRP: every spoke registers with the hub, and once two spokes need to talk to each other, they can build a tunnel straight there — without headquarters forwarding the traffic.
This note works through a full DSVPN Over IPSec build with a Cisco router as the hub and two Huawei AR routers as spokes: the mGRE tunnel interfaces, the NHRP registration and authentication, the IKE/IPSec parameters wrapped around the tunnel with an IPSec profile, and the verification that confirms spokes are actually finding each other directly instead of routing through the hub.
One hub, two spokes — and once NHRP resolves, a direct tunnel between the spokes themselves.
Diagram labels are kept in English for engineering clarity.
Addressing
| Item | Spoke1 — Huawei AR | Spoke2 — Huawei AR | Hub — Cisco |
|---|---|---|---|
| Public (WAN) address | 1.1.2.10 | 1.1.3.10 | 1.1.1.10 |
| Tunnel interface address | 10.2.1.2 | 10.2.1.3 | 10.2.1.1 |
| Private subnet | 10.1.1.0/24 | 10.1.2.0/24 | 10.1.0.0/24 |
NHRP Parameters
| Parameter | Value (this example) |
|---|---|
| NHRP network-id (domain) | 1000 |
| NHRP authentication key | huawei12 |
| Spoke registration interval | 1800 seconds |
| Hub NHRP holdtime | 3600 seconds |
Phase 1 — IKE Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| IKE version | IKEv1 |
| Negotiation mode | Main mode |
| Authentication method | Pre-shared key |
| Pre-shared key (this example) | huawei@123 — the source example's key; always set a unique key of your own. |
| Encryption algorithm | aes-cbc-128 |
| Authentication algorithm | sha1 |
| DH group | group5 |
| SA lifetime | 28800 seconds |
| DPD | Enabled (periodic) |
Phase 2 — IPSec Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| Security protocol | ESP |
| Encapsulation mode | Transport — mGRE already provides the outer tunnel |
| Encryption algorithm | aes-128 |
| Authentication algorithm | sha1 |
| SA lifetime | 3600 seconds (default) |
| PFS | Disabled |
The mGRE tunnel, NHRP registration and an IPSec profile bound straight to the tunnel interface — no crypto map, no ACL.
<Huawei> system-view
[Huawei] sysname Spoke1
[Spoke1] interface gigabitethernet 1/0/0
[Spoke1-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[Spoke1-GigabitEthernet1/0/0] quit
[Spoke1] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[Spoke1] interface Tunnel0/0/0
[Spoke1-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/0] nhrp network-id 1000
[Spoke1-Tunnel0/0/0] nhrp authentication simple huawei12
[Spoke1-Tunnel0/0/0] nhrp registration interval 1800
[Spoke1-Tunnel0/0/0] quit
[Spoke1] ip route-static 10.1.0.0 255.255.255.0 10.2.1.1
[Spoke1] ip route-static 10.1.2.0 255.255.255.0 10.2.1.3
[Spoke1] ike proposal 5
[Spoke1-ike-proposal-5] encryption-algorithm aes-cbc-128
[Spoke1-ike-proposal-5] authentication-algorithm sha1
[Spoke1-ike-proposal-5] dh group5
[Spoke1-ike-proposal-5] sa duration 28800
[Spoke1-ike-proposal-5] authentication-method pre-share
[Spoke1-ike-proposal-5] quit
[Spoke1] ike peer spoke1 v1
[Spoke1-ike-peer-spoke1] ike-proposal 5
[Spoke1-ike-peer-spoke1] pre-shared-key cipher huawei@123
[Spoke1-ike-peer-spoke1] exchange-mode main
[Spoke1-ike-peer-spoke1] dpd type periodic
[Spoke1-ike-peer-spoke1] quit
[Spoke1] ipsec proposal spoke1
[Spoke1-ipsec-proposal-spoke1] transform esp
[Spoke1-ipsec-proposal-spoke1] esp authentication-algorithm sha1
[Spoke1-ipsec-proposal-spoke1] esp encryption-algorithm aes-128
[Spoke1-ipsec-proposal-spoke1] encapsulation-mode transport
[Spoke1] ipsec profile profile1
[Spoke1-ipsec-profile-profile1] ike-peer spoke1
[Spoke1-ipsec-profile-profile1] proposal spoke1
[Spoke1-ipsec-profile-profile1] quit
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] ipsec profile profile1Same six steps, mirrored addressing — Spoke2's static routes point back at the hub and at Spoke1.
<Huawei> system-view
[Huawei] sysname Spoke2
[Spoke2] interface gigabitethernet 1/0/0
[Spoke2-GigabitEthernet1/0/0] ip address 1.1.3.10 255.255.255.0
[Spoke2-GigabitEthernet1/0/0] quit
[Spoke2] ip route-static 0.0.0.0 0.0.0.0 1.1.3.1
[Spoke2] interface Tunnel0/0/0
[Spoke2-Tunnel0/0/0] ip address 10.2.1.3 255.255.255.0
[Spoke2-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke2-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke2-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke2-Tunnel0/0/0] nhrp network-id 1000
[Spoke2-Tunnel0/0/0] nhrp authentication simple huawei12
[Spoke2-Tunnel0/0/0] nhrp registration interval 1800
[Spoke2-Tunnel0/0/0] quit
[Spoke2] ip route-static 10.1.0.0 255.255.255.0 10.2.1.1
[Spoke2] ip route-static 10.1.1.0 255.255.255.0 10.2.1.2
[Spoke2] ike proposal 5
[Spoke2-ike-proposal-5] encryption-algorithm aes-cbc-128
[Spoke2-ike-proposal-5] authentication-algorithm sha1
[Spoke2-ike-proposal-5] dh group5
[Spoke2-ike-proposal-5] sa duration 28800
[Spoke2-ike-proposal-5] authentication-method pre-share
[Spoke2-ike-proposal-5] quit
[Spoke2] ike peer spoke2 v1
[Spoke2-ike-peer-spoke2] ike-proposal 5
[Spoke2-ike-peer-spoke2] pre-shared-key cipher huawei@123
[Spoke2-ike-peer-spoke2] exchange-mode main
[Spoke2-ike-peer-spoke2] dpd type periodic
[Spoke2-ike-peer-spoke2] quit
[Spoke2] ipsec proposal spoke2
[Spoke2-ipsec-proposal-spoke2] transform esp
[Spoke2-ipsec-proposal-spoke2] esp authentication-algorithm sha1
[Spoke2-ipsec-proposal-spoke2] esp encryption-algorithm aes-128
[Spoke2-ipsec-proposal-spoke2] encapsulation-mode transport
[Spoke2] ipsec profile profile1
[Spoke2-ipsec-profile-profile1] ike-peer spoke2
[Spoke2-ipsec-profile-profile1] proposal spoke2
[Spoke2-ipsec-profile-profile1] quit
[Spoke2] interface tunnel 0/0/0
[Spoke2-Tunnel0/0/0] ipsec profile profile1The hub's mGRE interface is the multicast rendezvous point every spoke registers against — dynamic NHRP mapping replaces a static peer list.
Router#configure
Router(config)#interface gigabitethernet 0/1
Router(config-if)#ip address 1.1.1.10 255.255.255.0
Router(config-if)#exit
Router(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
Router(config)#interface tunnel 0
Router(config-if)#ip address 10.2.1.1 255.255.255.0
Router(config-if)#tunnel mode gre multipoint
Router(config-if)#tunnel source gigabitethernet0/1
Router(config-if)#ip nhrp holdtime 3600
Router(config-if)#ip nhrp network-id 1000
Router(config-if)#ip nhrp authentication huawei12
Router(config-if)#ip nhrp map multicast dynamic
Router(config-if)#exit
Router(config)#ip route 10.1.2.0 255.255.255.0 10.2.1.3
Router(config)#ip route 10.1.1.0 255.255.255.0 10.2.1.2
Router(config)#crypto isakmp policy 10
Router(config-isakmp)#hash sha
Router(config-isakmp)#encryption aes 128
Router(config-isakmp)#group 5
Router(config-isakmp)#authentication pre-share
Router(config-isakmp)#lifetime 28800
Router(config-isakmp)#exit
Router(config)#crypto isakmp key huawei@123 address 0.0.0.0 no-xauth
Router(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
Router(cfg-crypto-trans)#mode transport require
Router(cfg-crypto-trans)#exit
Router(config)#crypto ipsec profile profile1
Router(ipsec-profile)#set transform-set tran1
Router(ipsec-profile)#exit
Router(config)#interface tunnel 0
Router(config-if)#tunnel protection ipsec profile profile1
Router(config-if)#exitCisco-side syntax in this note was verified against Cisco IOS Software, C3900e-UNIVERSALK9-M, release 15.2(4)M1 — IOS-XE and ASA use related but not identical syntax.
Hub-Spoke dynamic tunnels bring their own failure modes on top of ordinary IPSec ones.
SYMPTOMA DSVPN design that works fine between Huawei devices in the lab runs into a compliance or licensing question once it's actually about to go into production with a non-Huawei hub.
CAUSEThe source configuration guide is explicit that DSVPN is a Huawei proprietary implementation, and interconnecting it with another vendor's equipment may carry legal risk — the guide instructs engineers to check with Huawei's local office and the legal department before doing exactly this. Some devices also gate the DSVPN feature behind a license that's restricted by default.
FIXConfirm DSVPN licensing is active on every Huawei spoke, and get the cross-vendor combination formally cleared before it goes into production — treat this as a day-one checklist item, not something discovered during a deployment.
SYMPTOMTwo spokes behind NAT register with the hub just fine, but the direct spoke-to-spoke tunnel between them never comes up, or comes up unreliably.
CAUSEDSVPN doesn't support spoke-to-spoke tunnels when both spokes sit behind the same NAT device translating them to the same address, and it doesn't support NAT traversal when the spokes are behind different NAT devices with PAT enabled. The NAT device in front of any DSVPN participant also has to be configured as a NAT server or static NAT — DSVPN doesn't work through ordinary NAT outbound or NAT inbound.
FIXIf a spoke sits behind NAT, use static NAT or a NAT server mapping for it rather than dynamic outbound/inbound NAT, and don't expect a direct spoke-to-spoke tunnel between two spokes sharing a PAT-enabled NAT device.
SYMPTOMOSPF (or another IGP) runs over the DSVPN tunnel, but routes between spokes don't propagate the way they should, or the spoke-to-spoke shortcut never actually gets used even after NHRP resolves.
CAUSEThe right network type and route-aggregation setting depends on whether the deployment is shortcut or non-shortcut. Non-shortcut needs horizontal split and automatic route aggregation disabled on the hub's mGRE interface, with OSPF's network type set to broadcast; shortcut needs the opposite — split and aggregation enabled, with OSPF set to point-to-multipoint — and a BGP shortcut design needs route aggregation configured on the hub specifically.
FIXDecide shortcut vs. non-shortcut before touching the routing protocol configuration, then set the network type and split/aggregation behavior to match — copying one design's routing settings onto the other silently breaks route propagation or the spoke-to-spoke shortcut.
SYMPTOMAn ike peer command that works on one spoke's firmware is rejected, or behaves unexpectedly, on another spoke of the same hardware family.
CAUSEVersions before V200R008 use ike peer peer-name [ v1 | v2 ] as a single command. V200R008 and later split this into ike peer peer-name plus a separate version { 1 | 2 } command, and the default IKE version behavior changed at the same boundary. remote-name and local-id-type name were likewise renamed to remote-id and local-id-type fqdn on newer versions.
FIXCheck the exact software version on each spoke before copying an IKE peer block between them — don't assume two spokes are running identical firmware just because they're the same hardware model.
SYMPTOMA spoke loses its WAN connection or reboots, but the peer's SA table still shows the old session as healthy for a while, and traffic destined for that spoke has nowhere useful to go in the meantime.
CAUSEWithout Dead Peer Detection, an IKE/IPSec session only gets torn down when its lifetime expires or a fresh negotiation fails — neither of which happens quickly if the peer simply vanished mid-session.
FIXEnable periodic DPD on each spoke's IKE peer so a dead session gets noticed and cleaned up promptly instead of waiting out the full SA lifetime.
[Spoke1-ike-peer-spoke1] dpd type periodicThe real test isn't the hub-spoke SA — it's whether two spokes can build a tunnel straight to each other.
[Spoke1] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
[Spoke1] display nhrp peer all
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
10.2.1.1 32 1.1.1.10 10.2.1.1 static hub
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 05:13:06
Expire time : --
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
10.2.1.3 32 1.1.3.10 10.2.1.3 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 00:00:31
Expire time : 01:59:29
[Spoke1] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
22 1.1.1.3 0 RD|ST 2
15 1.1.1.3 0 RD|ST 1
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1If the IPSec tunnel won't come up at all, check whether the route to the peer is actually reachable and whether both ends' IPSec configuration genuinely matches. If the DSVPN tunnel itself won't come up even though IPSec looks fine, check whether both ends' DSVPN configuration — NHRP network-id, authentication key and registration — actually matches.
Five questions that come up almost every time a Hub-Spoke DSVPN design like this one gets built.
Directly, once NHRP has resolved the far spoke's public address. Every spoke registers with the hub first — the hub always knows every spoke's real address — but as soon as one spoke needs to send traffic to another, NHRP lets it resolve that spoke's actual address and build a tunnel straight there. display nhrp peer all on either spoke shows the difference: the hub's entry is static, and the other spoke's entry flips to dynamic, tagged route tunnel, once the direct path is up.
No — this design binds IPSec directly to the tunnel interface with tunnel protection ipsec profile, referencing a crypto ipsec profile built from a transform-set. There's no crypto map and no ACL-matched traffic selector, because the mGRE tunnel interface itself defines what gets protected: everything riding that tunnel does.
It can work, but only within DSVPN's NAT limits: the device in front of the spoke has to do static NAT or act as a NAT server, not dynamic outbound/inbound NAT, and two spokes sharing a PAT-enabled NAT device can't build a direct tunnel to each other.
Non-shortcut needs a static or dynamic route on every device pointing at every other device's tunnel address directly — including spoke-to-spoke routes, as in this note's static-route example. Shortcut lets spokes learn reachability through the hub first and only builds the direct spoke-to-spoke tunnel on demand, which needs less manual route configuration but changes how OSPF's network type and route aggregation need to be set.
Exactly what the source guide flags: if the IPSec tunnel won't come up, check whether the route to the peer is actually reachable and whether both ends' IPSec configuration genuinely matches. If the DSVPN tunnel itself won't come up, check whether both ends' DSVPN configuration actually matches.
This note is based on the two-spoke, Cisco-hub DSVPN Over IPSec example from the source configuration guide, including its NAT restrictions and its routing-protocol table. It doesn't cover DSVPN with three or more spokes needing simultaneous shortcut tunnels, IKEv2, a non-Cisco hub, or dynamic routing protocols beyond the RIP/OSPF/BGP combinations the source guide documents.
How many spokes, which hub vendor, shortcut or not — send it over WhatsApp and we'll help you line up the parameters across every device.