PermitANY
Cisco IOS / IOS-XEConfig301 downloads

DMVPN Spoke — Cisco IOS/IOS-XE

Configure a DMVPN branch (spoke) router: mGRE tunnel, NHRP registration to the hub, and IPsec protection. Supports dynamic WAN IP, Phase 3 NHRP Shortcut for direct spoke-to-spoke tunnels, and EIGRP routing overlay.

↓ example.txt

What is it?

A DMVPN Spoke is any branch router that registers with the Hub (NHRP server) at boot. The spoke establishes an IPsec/IKE session to the hub and sends an NHRP Registration Request containing its own NBMA (WAN) IP. This works even if the spoke's WAN IP is dynamic (DHCP from ISP). Once registered, the spoke can reach all other spokes via the hub. In Phase 3, when the hub sends an NHRP Redirect, the spoke uses NHRP Shortcut routing to build a direct spoke-to-spoke tunnel bypassing the hub — essential for real-time traffic such as voice and video.

When to use

  • ·Any branch office in a DMVPN hub-and-spoke WAN
  • ·Branch with a dynamic public IP from ISP — NHRP registration works regardless of WAN IP
  • ·Branch that needs direct voice/video connectivity to other branches — enable Phase 3 shortcuts
  • ·Replacing a legacy point-to-point IPsec tunnel to HQ with a scalable DMVPN design

When NOT to use

  • ·Branch is the only remote site — use standard IPsec VTI for simplicity
  • ·Branch router is not Cisco — DMVPN is Cisco-proprietary; use standard IKEv2 site-to-site instead
  • ·Organization has migrated to FlexVPN — configure as a FlexVPN spoke (SVTI) instead

How it compares

vs Static IPsec VTI SpokeStatic VTI requires the hub to know your WAN IP in advance and creates a dedicated tunnel interface on the hub per spoke. DMVPN spoke uses mGRE — the hub has a single interface for all spokes and your WAN IP can be dynamic.
vs FlexVPN Spoke (SVTI)FlexVPN spoke uses a static VTI with IKEv2 and connects to a hub Dynamic VTI. FlexVPN supports per-tunnel QoS and requires IOS 15.2+. DMVPN spoke works on older IOS and is simpler to configure.
vs AnyConnect / Remote Access VPNRemote access VPN is for individual users on laptops/phones. DMVPN spoke is for site-to-site — an entire branch LAN behind a router connecting to HQ.

Prerequisites

  • →Hub router must be configured and reachable from the spoke's WAN IP
  • →hub_public_ip must be the Hub's actual WAN/NBMA IP — the spoke sends NHRP registration there
  • →NHRP network-id, authentication key, PSK, encryption, integrity, and DH group must match the hub exactly
  • →ip mtu 1400 prevents fragmentation: GRE adds 24 bytes + IPsec ESP adds up to 73 bytes over a standard 1500-byte MTU path
  • →IOS 12.4(6)T or later for Phase 2 | IOS 15.1(1)T or later for Phase 3 shortcuts

Config Generator

Must match the tunnel number used on all other routers in this DMVPN cloud

This spoke's overlay IP — must be unique within the DMVPN /24. Hub example: 10.255.0.1, Spokes: .10, .11, .12...

WAN-facing interface (e.g. GigabitEthernet0/0). Can also be a loopback or a specific IP address.

The Hub router's physical WAN IP. This is the NBMA address the spoke maps to the hub's tunnel IP.

The Hub router's overlay tunnel IP. The spoke sets this as its NHRP NHS (Next Hop Server).

Must be identical on hub and every spoke in this DMVPN cloud

Must match the hub and all other spokes in this DMVPN cloud

Must match the hub exactly

Must match the hub

Must match the hub

Must match the hub

When the hub sends an NHRP Redirect, this spoke installs a shortcut route and builds a direct IPsec tunnel to the destination spoke. Hub must also have 'ip nhrp redirect' configured.

Must match the hub

Verification commands

show dmvpn

This spoke's NHRP registration state with the hub

ExpectedState: UP, NBMA Addr = hub_public_ip. Attrb = S (spoke-to-hub static entry)

show ip nhrp

NHRP mapping table — static entry to hub plus any dynamic entries to other spokes

ExpectedStatic entry for hub tunnel IP → hub_public_ip (configured). Dynamic entries for other spokes appear after Phase 2/3 resolution.

show crypto session

IKE + IPsec session state to the hub

ExpectedUP-ACTIVE for the hub peer. Session should show ikev2 if IKEv2 is configured.

show crypto ikev2 sa

IKEv2 Phase 1 SA — verify cipher matched and SA is READY

ExpectedStatus: READY. Local/remote IKE identities visible. Encryption matches what you configured.

show ip eigrp neighbors

EIGRP adjacency to hub (and potentially to other spokes in Phase 2/3)

ExpectedHub tunnel IP appears as EIGRP neighbor via Tunnel interface

show ip route

Verify default route or hub summary route is received via EIGRP

ExpectedRoutes marked 'D' for hub LAN and other spokes' LANs

Debug commands

debug crypto condition peer ipv4 {{hub_public_ip}}

Scope all crypto debug to the hub peer only — always set before enabling debug

WarningRequired before any crypto debug to prevent flooding

debug crypto ikev2 packet

IKEv2 negotiation trace — shows proposal exchange and identifies mismatch

WarningSet conditional debug first. Disable with: undebug all

debug ip nhrp

NHRP registration and shortcut resolution events

WarningUse with caution. Useful for diagnosing Phase 3 spoke-to-spoke tunnel failures.

Common mistakes & fixes

Symptomshow dmvpn shows NHRP state IKE — never transitions to UP
CauseIKE Phase 1 failing — PSK mismatch, proposal mismatch (encryption/integrity/DH group), or IKEv1 vs IKEv2 mismatch between spoke and hub
FixVerify PSK, encryption, integrity, and DH group exactly match the hub. Run 'debug crypto ikev2 packet' with conditional peer debug to see the error.
SymptomSpoke registered (UP) but cannot reach hub LAN or other spoke LANs
CauseEIGRP not formed, or hub is not redistributing/advertising routes back to spokes
FixCheck 'show ip eigrp neighbors' — hub should appear. Check 'show ip route eigrp'. Verify hub has 'no ip split-horizon eigrp <AS>' on its tunnel interface.
SymptomPhase 3 direct spoke-to-spoke tunnel not building
Causeip nhrp shortcut not configured on this spoke, or ip nhrp redirect not configured on hub
FixThis spoke needs 'ip nhrp shortcut' on Tunnel interface. Hub needs 'ip nhrp redirect'. Check with: debug ip nhrp on spoke and watch for NHRP redirect messages.
SymptomTunnel comes up but large pings fail (MTU black hole)
CausePacket size + GRE (24B) + IPsec ESP (~73B) exceeds WAN path MTU of 1500B
FixVerify ip mtu 1400 and ip tcp adjust-mss 1360 on Tunnel interface. Test: ping {{hub_tunnel_ip}} size 1400 df-bit — should succeed with mtu 1400 configured.
SymptomSpoke behind NAT cannot establish IKE with hub
CauseNAT device blocking UDP 4500 (IKE NAT-T) or ESP (protocol 50)
FixIKEv2 handles NAT-T natively via UDP 4500. Verify the NAT device permits UDP 4500 to hub_public_ip. For IKEv1 add 'crypto isakmp nat-traversal 30' on both hub and spoke.

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

Kindle ↗Hardcover ↗

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

Paperback ↗

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

Kindle ↗Hardcover ↗Paperback ↗

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

Kindle ↗Paperback ↗

Related configs

cisco-ios-dmvpn-hub →cisco-ios-flexvpn →cisco-ios-vpn-ipsec →cisco-ios-base-config →