NetOps Toolkit

Cisco IOS

DMVPN Generator

Generate Cisco DMVPN hub/spoke configs with optional IPsec - Phase 1, 2 and 3

What is DMVPN?

Dynamic Multipoint VPN (DMVPN) is a Cisco IOS solution combining mGRE (Multipoint GRE), NHRP (Next Hop Resolution Protocol), and optionally IPsec to create a scalable hub-and-spoke overlay. Spokes register their public IPs with the hub dynamically, enabling on-demand spoke-to-spoke tunnels without per-spoke static config on the hub.

  • Spokes can have dynamic public IPs (DHCP from ISP) — no static config required on the hub.
  • Phase 2/3 allows spoke-to-spoke traffic to go directly without hairpinning through the hub.
  • Supports multicast (unlike plain IPsec) — OSPF, EIGRP, and BGP work over the tunnel.
  • Single mGRE interface on the hub replaces hundreds of point-to-point GRE tunnels.
  • IPsec is optional: skip it on trusted private WAN, add it for public internet deployments.

DMVPN Phases

PhaseSpoke-to-SpokeHow it WorksRouting Notes
Phase 1Always via HubClassic hub-and-spoke. All traffic flows through hub. Simplest to configure.Any dynamic routing protocol. Hub may summarize spoke routes.
Phase 2Direct after first packetHub sends NHRP redirect. Spoke learns peer NBMA IP and builds a direct mGRE tunnel dynamically.EIGRP: disable split-horizon on hub. OSPF: point-to-multipoint.
Phase 3Direct, scalableHub sends NHRP redirect; spoke sends NHRP resolution. Requires ip nhrp redirect on hub. Most scalable.BGP or EIGRP named mode recommended. No split-horizon issues.

Protocol Stack

IPsec ESP (optional) — Encrypts the GRE packet end-to-end
Outer IP Header — Public NBMA source/dest IPs (hub or spoke)
mGRE Header — Tunnel encapsulation, carries multicast/broadcast
Inner IP Packet — Original routed packet (tunnel overlay IPs)
GRE vs GRE over IPsec: Plain GRE carries multicast and dynamic routing but provides zero encryption. Add IPsec when traversing the public internet. For IPsec protocol details (IKEv1/IKEv2, AES, SHA), see WAN & VPN Services → VPN tab and Network Types → P2P & VPN tab in this toolkit.

Key Components

ComponentRoleDetails
mGRETunnel encapsulationSingle tunnel interface on hub handles all spokes. tunnel mode gre multipoint.
NHRPAddress resolutionMaps tunnel (overlay) IPs to NBMA (public) IPs. Like ARP for the tunnel subnet.
NHSNext Hop Server (Hub)Hub stores the NHRP registration database. Spokes register at boot.
NHCNext Hop Client (Spoke)Spoke registers its NBMA IP with the hub NHS on startup.
NBMA IPPublic/underlay IPReal routable IP used to reach the device — may be dynamic DHCP from ISP.
Tunnel IPOverlay IPIP on the tunnel interface — forms the DMVPN subnet (e.g. 10.0.0.0/24).
IPsec ProfileOptional encryptionAttached via tunnel protection ipsec profile. Uses transport mode.

Routing Over DMVPN

ProtocolPhase 1Phase 2Phase 3Notes
EIGRP Disable split-horizon on hub Named modeMost common on Cisco. Use no ip split-horizon eigrp on hub tunnel for Phase 2. See BGP & EIGRP tool.
OSPF point-to-multipoint point-to-multipointSet ip ospf network point-to-multipoint on tunnel. See OSPF Generator.
BGP RecommendedBest for Phase 3 at scale. No split-horizon issues. See BGP & EIGRP tool.
StaticVery small deployments only. See Static Route Generator.
For routing config help see BGP & EIGRP (NBMA neighbors, split-horizon), OSPF Generator (point-to-multipoint statements), or Static Route Generator. For IPsec background see WAN & VPN Services → VPN tab.

Show & Verify Commands

CommandPurpose
show dmvpnDMVPN session table — state, NBMA IPs, tunnel IPs, uptime
show dmvpn detailFull NHRP and tunnel session details per peer
show ip nhrpNHRP cache — tunnel-to-NBMA IP mappings
show ip nhrp detailFull NHRP entry details including flags and expiry
show tunnel endpointsActive GRE/mGRE tunnel endpoints
show crypto ikev2 saIKEv2 SA state and stats (if IPsec used)
show crypto ipsec saIPsec SA — encrypt/decrypt packet counters
show crypto isakmp saIKEv1 Phase 1 SA (legacy, if IKEv1 used)
show ip routeVerify routing protocol learned routes over tunnel
debug nhrpNHRP registration and redirect debug — use with caution in production

IPsec SA Resync

When the SAs of the peers get out of sync between peer devices, use the following commands to force a resync.

Force SA resync with a specific peer: 

clear crypto sa peer _____

Find and clear a specific ISAKMP SA by connection ID: 

show crypto isakmp sa
! Note the conn-id from the output, then clear by ID:
clear crypto isakmp conn_id <conn-id>

Verify IPsec peer sessions: 

show crypto ipsec sa | i peer