DMVPN Hub — Cisco IOS/IOS-XE
Configure the DMVPN Hub router: mGRE tunnel, NHRP server, IPsec with IKEv2 or IKEv1, and EIGRP routing overlay. Phase 3 NHRP Redirect included for spoke-to-spoke optimization.
What is it?
DMVPN (Dynamic Multipoint VPN) is a Cisco overlay technology that combines mGRE (Multipoint GRE), NHRP (Next Hop Resolution Protocol), and IPsec to build scalable hub-and-spoke WAN with optional direct spoke-to-spoke tunnels. The Hub is the NHRP server: it maintains a mapping table of every spoke's NBMA (physical WAN) address. Spokes register at boot. In Phase 3 the hub sends NHRP Redirect messages, telling the originating spoke to build a direct tunnel to the destination spoke rather than forwarding through HQ.
When to use
- ·Hub-and-spoke WAN with 10 to 1000+ branch offices
- ·Branch offices with dynamic ISP addresses — NHRP handles registration dynamically
- ·When spoke-to-spoke voice/video must not hairpin through HQ — use Phase 3
- ·Replacing individual point-to-point IPsec tunnels that don't scale — one mGRE interface replaces N static tunnel interfaces on the hub
- ·Existing Cisco-only infrastructure that cannot migrate to FlexVPN yet
When NOT to use
- ·2 to 3 sites — use standard IPsec VTI, far simpler
- ·Non-Cisco spokes — DMVPN is Cisco-proprietary; use standard IKEv2 site-to-site instead
- ·When per-spoke QoS shaping is required — use FlexVPN (Dynamic VTI) which creates individual virtual-access interfaces per spoke
- ·New deployments on IOS 15.2+ — FlexVPN is the strategic successor with better scalability and features
How it compares
Prerequisites
- →Hub must have a static public IP or a stable FQDN resolvable by spokes
- →IOS 12.4(6)T or later for DMVPN Phase 2 | IOS 15.1(1)T or later for Phase 3
- →ip mtu 1400 on the tunnel interface — GRE adds 24 bytes, IPsec ESP adds up to 73 bytes over a 1500-byte path MTU
- →EIGRP split-horizon must be disabled on the hub tunnel interface — by default EIGRP will not re-advertise routes learned from one spoke back out to other spokes
- →If using OSPF instead of EIGRP: set 'ip ospf network point-to-multipoint' on the hub tunnel interface
- →All routers in the DMVPN cloud must use matching: NHRP network-id, NHRP auth key, PSK, IKE encryption, integrity, and DH group
Config Generator
Creates interface Tunnel<N> — e.g. 0 for Tunnel0
Overlay IP on the DMVPN /24 — spokes will reference this IP as their NHS
WAN-facing interface name (e.g. GigabitEthernet0/1) or the WAN IP address
Arbitrary integer — must be identical on hub and every spoke in this DMVPN cloud
Shared NHRP secret — must match on all devices in this DMVPN cloud
IKE authentication key — must match on hub and all spokes
Group 14 is the minimum recommendation (RFC 8247). Groups 19-21 (ECDH) are faster and stronger but require IOS 15.x and hardware crypto support.
Hub sends NHRP Redirect to the originating spoke, triggering a direct spoke-to-spoke tunnel. Required for Phase 3. Spokes also need 'ip nhrp shortcut'.
Must match on hub and all spokes
Verification commands
show dmvpnOverview of all registered spokes with NBMA IP, tunnel IP, and NHRP state
ExpectedEach spoke shows State: UP. Intf column shows mGRE type.
show ip nhrpFull NHRP mapping table — dynamic entries are registered spokes
ExpectedDynamic entries: one per registered spoke. Flags: registered, used, router
show crypto session briefIKE + IPsec session state per peer at a glance
ExpectedUP-ACTIVE = both IKE SA and IPsec SA established. UP-IDLE = up but no recent traffic (normal).
show crypto ikev2 saIKEv2 Phase 1 SA — verify proposal negotiated and lifetime
ExpectedStatus: READY. Both local and remote proposals should show negotiated cipher.
show crypto ipsec sa peer <spoke-ip>Phase 2 SA counters for a specific spoke — verify encryption is working
Expected#pkts encaps and #pkts encrypt should increment when traffic flows to that spoke
show ip eigrp neighborsEIGRP adjacency over the DMVPN tunnel
ExpectedAll spokes appear as EIGRP neighbors via Tunnel interface. Uptime should be stable.
show ip route eigrpRoutes learned from spokes via EIGRP
ExpectedRoutes marked 'D' for each spoke's LAN subnet
Debug commands
debug crypto condition peer ipv4 <spoke-ip>Scope ALL crypto debug output to one peer — always run this before enabling any crypto debug
WarningSet this FIRST. Without it, crypto debug floods the console with all peers.
debug crypto ikev2 packetIKEv2 exchange messages — identifies proposal mismatch, auth failure, or DH group issue
WarningRun after setting conditional debug. Disable with: undebug all
debug ip nhrpNHRP registration and redirect events — diagnose spoke registration failures and Phase 3 issues
WarningCan be verbose on a large hub with many spokes
Common mistakes & fixes
Further learning
Recommended books to go deeper on this topic.
CCNP Security Virtual Private Networks SVPN 300-730 Official Cert Guide
Joseph Muniz, Steven Chimes, James Risler · Cisco Press · The only Cisco-approved SVPN study guide — covers DMVPN, FlexVPN, GETVPN, AnyConnect, and IKEv2 in depth
IKEv2 IPsec Virtual Private Networks — Understanding and Deploying IKEv2, IPsec VPNs, and FlexVPN in Cisco IOS
Graham Bartlett, Amjad Inamdar · Cisco Press · The definitive IKEv2 and FlexVPN reference — crypto fundamentals, keyring, profiles, DVTI, spoke-to-spoke
Network Security Technologies and Solutions
Yusuf Bhaiji · Cisco Press · CCIE Professional Development · Comprehensive CCIE Security reference — IPsec, IKE, VPN, AAA, PKI, firewalls all in one volume
CCNP and CCIE Security Core SCOR 350-701 Official Cert Guide
Omar Santos · Cisco Press · Required for CCNP/CCIE Security — covers VPN, cryptography, network security architecture