What Is DMVPN and Why Phase 2?
Dynamic Multipoint VPN (DMVPN) is one of the most elegant solutions Cisco has built for connecting a hub site to dozens or hundreds of remote spokes without managing an explosion of static crypto maps or GRE tunnels. If you’ve ever stared at a config with 80 individual tunnel interfaces — one per branch — you already understand the pain DMVPN solves.
DMVPN comes in three phases. Phase 1 is the simplest: all spoke-to-spoke traffic hairpins through the hub. It’s easy to configure but inefficient. Phase 3 uses NHRP redirect and shortcut switching for the most scalable spoke-to-spoke forwarding. Phase 2 is the sweet spot for most enterprise deployments — it allows spokes to build direct IPsec tunnels to each other on demand, cutting out the hub for inter-branch traffic, while remaining simpler to reason about than Phase 3.
This guide walks you through a complete DMVPN Phase 2 configuration on Cisco IOS-XE, covering the hub, multiple spokes, EIGRP-based routing, and the verification and troubleshooting commands you’ll actually use in production. All examples are tested on IOS-XE 17.x running on CSR1000v, ISR 4000-series, and ASR 1000-series platforms.
Lab Topology
The lab uses three routers:
- HUB1 — The DMVPN hub, public IP 203.0.113.1
- SPOKE1 — Branch A, public IP 198.51.100.10, LAN 10.1.1.0/24
- SPOKE2 — Branch B, public IP 198.51.100.20, LAN 10.2.2.0/24
Tunnel network: 172.16.0.0/24 (mGRE addresses used by all DMVPN participants):
- HUB1 tunnel: 172.16.0.1
- SPOKE1 tunnel: 172.16.0.10
- SPOKE2 tunnel: 172.16.0.20
All three routers are running IOS-XE 17.x on CSR1000v or physical ISR/ASR platforms. The config is identical across IOS-XE versions for DMVPN fundamentals.
IKEv2 and IPsec Profile
Phase 2 DMVPN uses IPsec to encrypt the mGRE tunnel. You need a consistent IKEv2 proposal, policy, keyring, and profile — shared between hub and all spokes.
IKEv2 Configuration (all routers)
! IKEv2 Proposal
crypto ikev2 proposal DMVPN-PROP
encryption aes-cbc-256
integrity sha256
group 14
!
! IKEv2 Policy
crypto ikev2 policy DMVPN-POL
proposal DMVPN-PROP
!
! Pre-shared key keyring (wildcard for spokes connecting to hub)
crypto ikev2 keyring DMVPN-KEYS
peer ANY
address 0.0.0.0 0.0.0.0
pre-shared-key local Igna$DMVPNkey2026
pre-shared-key remote Igna$DMVPNkey2026
!
!
! IKEv2 Profile
crypto ikev2 profile DMVPN-PROF
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local DMVPN-KEYS
!
! IPsec Transform Set
crypto ipsec transform-set DMVPN-TS esp-aes 256 esp-sha256-hmac
mode transport
!
! IPsec Profile
crypto ipsec profile DMVPN-IPSEC
set transform-set DMVPN-TS
set ikev2-profile DMVPN-PROF
Note mode transport on the transform set — this is critical for mGRE/DMVPN. Using mode tunnel here will break things because GRE already provides the outer encapsulation. Transport mode encrypts only the GRE payload, avoiding double-encapsulation overhead.
Hub Configuration
Tunnel Interface
interface Tunnel0
description DMVPN-HUB
ip address 172.16.0.1 255.255.255.0
no ip split-horizon eigrp 100
no ip next-hop-self eigrp 100
ip nhrp authentication NHRP$Auth26
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN-IPSEC
Two lines here are mandatory for Phase 2 and often forgotten:
no ip split-horizon eigrp 100— Without this, the hub won’t advertise routes it learned from SPOKE1 back out the same tunnel interface to SPOKE2. Split horizon breaks the full routing table on spokes.no ip next-hop-self eigrp 100— Without this, EIGRP rewrites the next-hop to the hub’s tunnel IP. Spokes would send inter-spoke traffic to the hub instead of building direct tunnels. This is the key difference between Phase 1 and Phase 2 behavior.
Physical Interface on Hub
interface GigabitEthernet0/0/0
description WAN-UPLINK
ip address 203.0.113.1 255.255.255.0
no shutdown
!
interface GigabitEthernet0/0/1
description HUB-LAN
ip address 10.0.0.1 255.255.255.0
no shutdown
EIGRP on Hub
router eigrp 100
network 172.16.0.0 0.0.0.255
network 10.0.0.0 0.0.0.255
no auto-summary
Spoke Configuration
Spoke configs are nearly identical — only the tunnel IP, NHRP NHS mapping, and LAN subnet differ.
SPOKE1 Tunnel Interface
interface Tunnel0
description DMVPN-SPOKE1
ip address 172.16.0.10 255.255.255.0
ip nhrp authentication NHRP$Auth26
ip nhrp map 172.16.0.1 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 1
ip nhrp nhs 172.16.0.1
ip nhrp holdtime 300
ip nhrp registration no-unique
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN-IPSEC
SPOKE1 Physical and LAN
interface GigabitEthernet0/0/0
description WAN-UPLINK
ip address 198.51.100.10 255.255.255.0
no shutdown
!
interface GigabitEthernet0/0/1
description SPOKE1-LAN
ip address 10.1.1.1 255.255.255.0
no shutdown
SPOKE1 EIGRP
router eigrp 100
network 172.16.0.0 0.0.0.255
network 10.1.1.0 0.0.0.255
no auto-summary
SPOKE2 Tunnel Interface
interface Tunnel0
description DMVPN-SPOKE2
ip address 172.16.0.20 255.255.255.0
ip nhrp authentication NHRP$Auth26
ip nhrp map 172.16.0.1 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 1
ip nhrp nhs 172.16.0.1
ip nhrp holdtime 300
ip nhrp registration no-unique
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN-IPSEC
SPOKE2 Physical and LAN
interface GigabitEthernet0/0/0
description WAN-UPLINK
ip address 198.51.100.20 255.255.255.0
no shutdown
!
interface GigabitEthernet0/0/1
description SPOKE2-LAN
ip address 10.2.2.1 255.255.255.0
no shutdown
SPOKE2 EIGRP
router eigrp 100
network 172.16.0.0 0.0.0.255
network 10.2.2.0 0.0.0.255
no auto-summary
How Phase 2 Dynamic Tunnels Actually Work
Here’s the flow when SPOKE1 tries to reach SPOKE2’s LAN (10.2.2.0/24) for the first time:
- SPOKE1 looks up 10.2.2.x in its routing table. EIGRP has advertised this route with a next-hop of 172.16.0.20 (SPOKE2’s tunnel IP) — this works because the hub has
no ip next-hop-self eigrp 100. - SPOKE1 needs to resolve 172.16.0.20 to a real public IP. It sends an NHRP Resolution Request to the hub (its NHS).
- The hub has SPOKE2’s NBMA (public) address in its NHRP cache (from SPOKE2’s registration). It replies with an NHRP Resolution Reply containing 198.51.100.20.
- SPOKE1 initiates IKEv2 directly to 198.51.100.20 and builds a spoke-to-spoke IPsec/GRE tunnel on demand.
- Traffic flows directly between spokes. The hub is out of the data path.
This spoke-to-spoke tunnel is ephemeral — it tears down after ip nhrp holdtime expires with no traffic. Subsequent connections rebuild it automatically.
Verification Commands
Check DMVPN State (Hub)
HUB1# show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletei
T1 - Route Installed, T3 - Nexthop-override
C - Conn, L - Local, X - No Socket
1 peers in total, 2 active sockets
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 198.51.100.10 172.16.0.10 UP 00:12:34 D
1 198.51.100.20 172.16.0.20 UP 00:08:20 D
Both spokes show as Dynamic (D) registrations — that’s exactly what you want on the hub.
NHRP Cache
HUB1# show ip nhrp
172.16.0.10/32 via 172.16.0.10
Tunnel0 created 00:12:34, expire 00:07:25
Type: dynamic, Flags: registered used nhop
NBMA address: 198.51.100.10
172.16.0.20/32 via 172.16.0.20
Tunnel0 created 00:08:20, expire 00:08:20
Type: dynamic, Flags: registered used nhop
NBMA address: 198.51.100.20
Crypto Sessions (Spoke)
SPOKE1# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 203.0.113.1 port 4500
Session ID: 1
IKEv2 SA: local 198.51.100.10/4500 remote 203.0.113.1/4500 Active
IPSEC FLOW: permit 47 host 198.51.100.10 host 203.0.113.1
Active SAs: 2, origin: crypto map
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 198.51.100.20 port 4500
Session ID: 2
IKEv2 SA: local 198.51.100.10/4500 remote 198.51.100.20/4500 Active
IPSEC FLOW: permit 47 host 198.51.100.10 host 198.51.100.20
Active SAs: 2, origin: crypto map
Two crypto sessions on SPOKE1: one to the hub (permanent) and one to SPOKE2 (dynamic, built on demand).
EIGRP Neighbors and Routes
SPOKE1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.16.0.1 Tu0 13 00:15:42 8 200 0 42
SPOKE1# show ip route eigrp
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/24 [90/27008000] via 172.16.0.1, 00:15:30, Tunnel0
D 10.2.2.0/24 [90/28288000] via 172.16.0.20, 00:08:15, Tunnel0
Note that 10.2.2.0/24 shows next-hop 172.16.0.20 (SPOKE2’s tunnel IP), not 172.16.0.1. This confirms no ip next-hop-self is working correctly.
Common Pitfalls and Troubleshooting
1. Split Horizon Breaking Spoke-to-Hub Routes
If spokes can’t reach the hub LAN or each other’s prefixes, verify split horizon is disabled on the hub tunnel:
HUB1# show ip interface Tunnel0 | include split
Split horizon is disabled
If it says “enabled,” add no ip split-horizon eigrp 100 under the tunnel interface and reset EIGRP neighbors.
2. Spoke-to-Spoke Traffic Still Hairpinning via Hub
Check the routing table on the spoke. If 10.2.2.0/24 shows via 172.16.0.1 (hub) instead of via 172.16.0.20, the issue is ip next-hop-self still enabled on the hub:
HUB1# show running-config interface Tunnel0 | include next-hop
If you see ip next-hop-self eigrp 100, that line is overriding the EIGRP next-hop. Remove it.
3. IPsec Tunnel Won’t Come Up
Enable IKEv2 debugging briefly:
SPOKE1# debug crypto ikev2 packet
SPOKE1# debug crypto ikev2 error
Common causes: mismatched pre-shared keys, asymmetric NAT breaking UDP 500/4500, or mismatched IKEv2 proposals. Make sure both sides have identical encryption/integrity/DH group settings. Also verify the transform set is in mode transport, not mode tunnel.
4. NHRP Registration Failing
SPOKE1# debug nhrp
NHRP: Attempting to send packet via DEST 203.0.113.1
NHRP: Encapsulation succeeded. Tunnel Src/Dst: 172.16.0.10/172.16.0.1
NHRP: No NHRP map found for 172.16.0.1
If you see “No NHRP map found,” the static NHRP mapping on the spoke is missing or wrong:
ip nhrp map 172.16.0.1 203.0.113.1
ip nhrp map multicast 203.0.113.1
Both lines must be present. The multicast map is what allows EIGRP hellos to reach the hub.
5. Spoke Behind NAT
If your spoke is behind a PAT device (common in smaller branches), add ip nhrp registration no-unique on the spoke. Without it, re-registrations after NAT binding changes fail with “duplicate registration” errors. This flag is already included in the spoke config above.
OSPF Alternative Routing
Some deployments prefer OSPF over EIGRP. With OSPF on DMVPN Phase 2, you need to configure the tunnel as a point-to-multipoint non-broadcast network type on the hub to prevent the hub from being elected DR (which breaks direct spoke communication) while still allowing neighbor statements.
! Hub tunnel interface addition
ip ospf network point-to-multipoint non-broadcast
ip ospf 1 area 0
!
! Hub OSPF
router ospf 1
neighbor 172.16.0.10 cost 10
neighbor 172.16.0.20 cost 10
!
! Spoke tunnel interface addition
ip ospf network point-to-multipoint non-broadcast
ip ospf 1 area 0
The key constraint with OSPF on DMVPN Phase 2: you don’t get the automatic next-hop preservation that EIGRP provides with no ip next-hop-self. OSPF always uses the router’s own IP as next-hop, which forces spoke-to-spoke traffic back through the hub. For Phase 2 with OSPF, you must use point-to-multipoint and rely on NHRP shortcutting, or consider moving to Phase 3. EIGRP is genuinely simpler for Phase 2 deployments — this is one case where the protocol choice matters architecturally. For a deeper look at how OSPF adjacencies can break under these conditions, see OSPF Troubleshooting on Cisco IOS-XE.
Scaling Considerations
DMVPN Phase 2 scales well to 200–500 spokes per hub — beyond that, NHRP resolution latency and IKEv2 session overhead on the hub become bottlenecks. For larger deployments, consider:
- Dual-hub redundancy: Deploy two hubs (HUB1 and HUB2), configure both as NHS on spokes with
ip nhrp nhs priority, and redistribute into EIGRP with different metrics to prefer one hub. - DMVPN Phase 3: Uses NHRP shortcuts to keep Phase 2 spoke-to-spoke efficiency while supporting larger spoke counts and hierarchical designs.
- SD-WAN overlay: Cisco vManage/Catalyst SD-WAN uses DMVPN concepts internally. If you’re evaluating a migration path, understand Phase 2 first — the forwarding model is nearly identical.
For environments where you’re also routing BGP prefixes over DMVPN (common when the hub is co-located with a data center aggregation router), DMVPN pairs cleanly with an iBGP full mesh or route reflector setup. See Understanding BGP for the foundational concepts before layering BGP on top of a DMVPN design.
Quick Reference: Key Commands
| Command | Purpose |
|---|---|
show dmvpn detail |
DMVPN state for all peers, flags |
show ip nhrp |
NHRP cache — NBMA-to-tunnel mappings |
show crypto session |
IKEv2/IPsec sessions and SA status |
show crypto ikev2 sa detail |
Detailed IKEv2 SA info, rekey timers |
show ip eigrp neighbors |
EIGRP neighbor adjacencies over tunnel |
show ip route eigrp |
Verify spoke next-hops (Phase 2 test) |
debug nhrp |
NHRP registration/resolution events |
debug crypto ikev2 packet |
IKEv2 negotiation packets |
clear ip nhrp |
Flush NHRP cache (forces re-registration) |
Wrapping Up
DMVPN Phase 2 remains one of the most practical VPN architectures for enterprises with many branch sites. The combination of mGRE, NHRP, and IPsec gives you a scalable, encrypted overlay where spoke-to-spoke traffic bypasses the hub entirely once the dynamic tunnel is established — without the additional complexity of Phase 3’s redirect mechanism.
The two lines that make or break Phase 2 are no ip split-horizon eigrp and no ip next-hop-self eigrp on the hub tunnel. Get those right, match your IKEv2 parameters and transform set mode across all devices, and the rest follows naturally.
If you’re managing your DMVPN infrastructure at scale and want to automate configuration deployment or compliance checking across your spoke fleet, Network Automation with Python, Netmiko, NAPALM, and Nornir is the logical next step — scripting NHRP map and tunnel builds across 50 spokes is exactly the kind of repetitive task automation handles better than a copy-paste marathon. And because DMVPN spokes often sit at sites that also run BGP upstream for redundant ISP links, understanding how to filter and influence those prefixes pays dividends for the overall design.
Leave a Reply