DMVPN: The Complete Guide

DMVPN (Dynamic Multipoint VPN) is Cisco's answer to a problem every multi-site network hits eventually: full-mesh connectivity without full-mesh configuration. Instead of building and maintaining a static tunnel between every pair of sites, you configure one multipoint GRE tunnel interface per router, point the spokes at a hub, and let NHRP discover the rest. Spoke-to-spoke tunnels come up on demand, carry traffic directly, and tear themselves down when idle. If you are studying for the ENARSI exam (where VPN technologies carry roughly 20 percent of the weight) or running branch connectivity over the internet, DMVPN is one of those technologies you need to understand at the packet level, not just the config level.

This guide covers what DMVPN solves, how mGRE, NHRP, and your routing protocol fit together, what actually changes between Phase 1, Phase 2, and Phase 3, a working Phase 3 configuration on Cisco IOS XE with real lab output, routing and IPsec design choices, and the troubleshooting patterns that catch most broken deployments. Every command output here was captured from a live CML lab running IOS XE 17.18.

What DMVPN Solves

A classic hub-and-spoke VPN with point-to-point GRE tunnels scales linearly in configuration and quadratically in pain. Ten sites in a full mesh means 45 tunnels, 90 tunnel interfaces, and 90 chances to typo a tunnel destination. Every new site touches every existing router. Static tunnels also pin you to static addressing: if a branch sits behind DHCP or moves providers, the hub config changes too.

DMVPN collapses all of that into one interface per router. The hub needs zero per-spoke configuration (new spokes register themselves), spokes need only the hub's address, and spoke-to-spoke traffic can flow directly instead of hairpinning through the hub. You get the operational simplicity of hub-and-spoke with the traffic patterns of a mesh. That combination is why DMVPN ran most enterprise WANs for a decade and why SD-WAN platforms quietly reuse many of its ideas.

DMVPN is an overlay, so it rides over any IP transport: the internet, MPLS, LTE, or a lab underlay. The underlay only needs to deliver packets between tunnel source addresses. Everything interesting happens in the overlay, which is where this cluster spends its time. If GRE itself is new to you, start with the GRE complete guide and the mGRE and DMVPN introduction, then come back.

How DMVPN Works

DMVPN is not a protocol. It is a recipe with three mandatory ingredients and one optional ingredient, and the way they interlock is the whole exam topic:

mGRE (multipoint GRE) gives each router a single tunnel interface with no fixed destination. One interface, many peers. Because the destination is not configured, the router needs some way to learn "to reach overlay address X, send the GRE packet to underlay address Y." That mapping is exactly what NHRP provides. We break the encapsulation mechanics down in DMVPN explained: mGRE + NHRP + routing in one overlay.

NHRP (Next Hop Resolution Protocol, RFC 2332) is the address book. Spokes register their overlay-to-underlay binding with the hub (the Next Hop Server) at boot, and later query the hub to resolve other spokes on demand. In Phase 3 the hub also sends redirect messages that tell spokes "you two should talk directly." Registration, resolution, and redirects each have distinct packet types and distinct failure modes, covered in the NHRP deep dive.

A routing protocol runs over the tunnel and distributes the LAN prefixes behind each site. NHRP knows how to reach tunnel endpoints; the routing protocol knows what networks live behind them. EIGRP and OSPF are the usual choices and their design trade-offs over an NBMA overlay are surprisingly different, which is the subject of routing over DMVPN.

IPsec is optional but near-universal in production, because GRE is cleartext. A tunnel protection profile bolts IKEv2-negotiated encryption onto the mGRE interface without changing any of the DMVPN logic. Configuration and verification live in securing DMVPN with IPsec profiles.

DMVPN Component Reference

The Three Phases: DMVPN's Core Design Decision

"Phase" in DMVPN is not a negotiation state or a rollout stage. It is a design choice you make in configuration, and it controls one thing: how spoke-to-spoke traffic flows. Phase 1 sends everything through the hub. Phase 2 lets spokes build direct tunnels but forces the routing protocol to preserve spoke next hops, which kills summarization. Phase 3 fixes that with two NHRP commands (ip nhrp redirect on the hub, ip nhrp shortcut on the spokes) that let the routing design stay simple while the data plane finds shortcuts on its own.

The full walkthrough, with the same lab migrated live from Phase 1 to Phase 3 and the routing table captured at each step, is in DMVPN Phase 1 vs Phase 2 vs Phase 3: what actually changes.

Configuration on Cisco IOS XE: Minimum Viable DMVPN Phase 3

This is the working Phase 3 configuration from our lab: one hub, two spokes, an INET router simulating the underlay, EIGRP named mode over the top. The hub tunnel:

interface Tunnel0
 description DMVPN hub - mGRE
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication PLZ123
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel source Ethernet0/1
 tunnel mode gre multipoint
 tunnel key 100

And the spoke tunnel (the only per-spoke uniqueness is its own IP addressing):

interface Tunnel0
 description DMVPN spoke - mGRE
 ip address 10.0.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication PLZ123
 ip nhrp map 10.0.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
 ip nhrp shortcut
 tunnel source Ethernet0/1
 tunnel mode gre multipoint
 tunnel key 100

Once the spokes register, the hub sees them as dynamic (D) NHRP peers with zero per-spoke configuration:

HUB# show dmvpn
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.1           10.0.0.2    UP 00:01:35     D
     1 192.0.2.1              10.0.0.3    UP 00:01:31     D

The Phase 3 payoff shows up the first time one spoke LAN talks to another. The first traceroute rides through the hub, the hub fires an NHRP redirect, the spokes resolve each other, and the second traceroute goes direct:

SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1 10.0.0.1 2 msec 1 msec 2 msec
  2 10.0.0.3 3 msec *  2 msec
SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1  *
    10.0.0.3 4 msec *

Behind the scenes the RIB grows a next-hop override (the % marker and [NHO] entry) pointing the spoke LAN prefix straight at the other spoke:

SPOKE1# show ip route next-hop-override
H        10.0.0.3/32 is directly connected, 00:00:09, Tunnel0
D   %    10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:00:57, Tunnel0
                     [NHO][90/255] via 10.0.0.3, 00:00:09, Tunnel0

The full build, including the underlay, EIGRP configuration, and every verification step, is in DMVPN Phase 3 configuration on Cisco IOS XE. Note the ip mtu 1400 and ip tcp adjust-mss 1360 lines: GRE overhead plus IPsec overhead will fragment full-size packets without them, a failure mode explained in GRE MTU and fragmentation.

Routing Over DMVPN

The routing protocol is where DMVPN designs succeed or quietly rot. Two behaviors matter on a hub that relays routes between spokes on the same tunnel interface. Split horizon stops EIGRP from re-advertising a spoke's routes back out Tunnel0 to the other spokes, so the hub needs no split-horizon under the tunnel's af-interface. Next-hop-self decides whether the hub rewrites the next hop to itself: in Phase 2 you had to disable it so spokes learned each other's tunnel addresses; in Phase 3 you leave it on and let NHRP shortcuts override the RIB instead.

OSPF brings a different set of constraints because it thinks in network types. Broadcast mode over DMVPN means DR elections on an NBMA cloud (fragile), while point-to-multipoint mode treats the cloud as a set of host routes with the hub as next hop, which is slower to converge but boring and reliable. Our lab captures show OSPF p2mp producing /32 host routes for every tunnel endpoint while NHRP shortcuts still steer the actual traffic spoke-to-spoke. EIGRP versus OSPF trade-offs, timers, and the capture-backed comparison are in routing over DMVPN: EIGRP and OSPF design choices, with background in the EIGRP and OSPF guides.

Securing DMVPN

Everything above runs in cleartext. Production DMVPN over the internet adds an IPsec profile to the tunnel interface: an IKEv2 proposal and profile define authentication and key exchange, a transform set picks the ESP cipher (AES-GCM in transport mode is the modern default), and tunnel protection ipsec profile ties it to the mGRE interface. The DMVPN control plane does not change at all; NHRP and the routing protocol just start flowing through ESP. Verification is two commands:

HUB# show crypto ikev2 sa
Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.1/500       203.0.113.2/500       none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19

A reasonable hardening checklist for a DMVPN edge: IKEv2 only (no IKEv1 fallback), certificate or strong PSK authentication per peer, NHRP authentication strings on every tunnel (they are weak but they catch misconfig), a tunnel key to separate overlapping clouds, control-plane policing on the hub, and an underlay ACL that permits only ESP, IKE, and GRE from expected sources. The complete IKEv2 build with real SA output from Catalyst 8000V routers is in securing DMVPN with IPsec profiles (IKEv2), and the broader design question of what belongs inside which encapsulation is covered in GRE over IPsec.

Troubleshooting: Common DMVPN Failures

Most DMVPN tickets reduce to one question: is the failure in the underlay, NHRP, the routing protocol, or IPsec? The show dmvpn peer state column answers half of it on its own. A peer stuck in state NHRP instead of UP means registration or resolution is failing; the classics are a wrong NHS address (requests sent into the void), an NHRP authentication mismatch (the hub logs %DMVPN-3-DMVPN_NHRP_ERROR ... authentication failure), and a tunnel key mismatch, which is the cruelest because both tunnels stay up/up while GRE silently drops every packet and the hub logs nothing at all. All three were broken on purpose in our lab and captured, with the fix path for each, in troubleshooting DMVPN. General tunnel-layer symptoms (recursive routing, MTU blackholes, keepalives) are in the GRE troubleshooting guide.

The Full DMVPN Cluster, in Reading Order

FAQ

Is DMVPN still relevant now that SD-WAN exists?

Yes, on three fronts. Thousands of production networks still run it and someone has to operate them. The ENARSI exam tests it heavily. And SD-WAN control planes borrow its concepts directly (overlay tunnels, central registration, dynamic peer discovery), so DMVPN knowledge transfers almost one-to-one. It remains the cheapest way to mesh sites when you own both ends and do not want a controller subscription.

Which DMVPN phase should I deploy?

Phase 3, essentially always. It scales the routing design (you can summarize aggressively, even push just a default route to spokes) while still building direct spoke-to-spoke tunnels. Phase 1 survives only where spoke-to-spoke traffic genuinely never happens, and Phase 2 exists mainly in older deployments and exam questions.

Does the NHRP network-id have to match between hub and spokes?

No, and this is a persistent myth. The network-id is locally significant; it groups tunnel interfaces into an NHRP domain on that router. What must actually match across routers are the NHRP authentication string, the tunnel key, and (for registration to work) the NHS address pointing at the hub's real tunnel IP.

Can I run DMVPN without IPsec?

Mechanically yes; mGRE and NHRP have no dependency on encryption, and lab work is often cleaner without it. Over any untrusted transport you should treat IPsec as mandatory, since GRE offers no confidentiality or integrity. The standard design is an IKEv2 profile applied with tunnel protection, which changes nothing about the DMVPN logic itself.

What MTU should a DMVPN tunnel use?

The convention is ip mtu 1400 and ip tcp adjust-mss 1360 on every tunnel interface. GRE adds 24 bytes, IPsec adds 50 to 70 more depending on cipher, and 1400 leaves comfortable headroom over a 1500-byte underlay while the MSS clamp keeps TCP from ever needing fragmentation.

Key Takeaways

DMVPN combines mGRE (one interface, many peers), NHRP (the overlay-to-underlay address book), and a routing protocol (prefix distribution) into a hub-and-spoke overlay that builds spoke-to-spoke tunnels on demand. The phases differ only in how spoke-to-spoke traffic flows: through the hub in Phase 1, via preserved next hops in Phase 2, and via NHRP redirects plus shortcuts in Phase 3, which is the design you should deploy. The hub needs zero per-spoke configuration, spokes need five NHRP lines, and IPsec bolts on with a tunnel protection profile without touching any of it. When it breaks, read the show dmvpn state column first: NHRP state means registration or resolution problems, and a tunnel that is up/up while passing nothing is a tunnel key mismatch until proven otherwise. Start with the explainer, build the Phase 3 lab, then break it with the troubleshooting guide.

Routing over DMVPN at expert depth

An mGRE tunnel is one interface with many neighbours behind it, and every distance-vector assumption built for point-to-point links breaks on it. Two commands on the hub - no split-horizon and no next-hop-self - are the difference between a dynamic mesh and a hub-and-spoke network wearing a costume: EIGRP over DMVPN: multi-hub design and the split-horizon problem.

A dual-homed branch introduces a second problem - the site learns its own prefixes back from the WAN, and EIGRP has no AS-path to catch it: EIGRP Site of Origin. Making one hub primary is a one-line job with an offset list.

Expert Transport: 6VPE, PE-CE BGP, and Dual-Hub DMVPN (CCIE level)

These articles close the CCIE transport domain. Built on real Cisco IOS XE output from two CML labs - a five-router MPLS L3VPN carrying VPNv4 and VPNv6, and a dual-hub IPsec DMVPN - they cover the label stacks, the BGP PE-CE edge cases, and the failover behaviour that separates a working transport from a resilient one.

Studying for the CCIE?

This cluster is part of the full CCNA to CCNP to CCIE Enterprise ladder on PingLabz, every rung built on real Cisco output. For expert-level depth across every EI v1.1 blueprint domain - and the four integration Super Labs - see the CCIE Enterprise Infrastructure study hub.