DMVPN has a reputation for being complicated, and it is entirely undeserved. The technology is three well-understood pieces (multipoint GRE, NHRP, and a routing protocol) assembled so that each covers a gap the others leave. Once you can say what each piece knows and what it does not know, every DMVPN behavior, from spoke registration to dynamic spoke-to-spoke tunnels, becomes predictable. This article walks the whole assembly with real output from a live IOS XE 17.18 lab: a hub, two spokes, and an underlay router standing in for the internet. It is the conceptual companion to the DMVPN complete guide and assumes you know basic GRE from the GRE guide.
The Problem: Tunnels Do Not Scale by Hand
A point-to-point GRE tunnel needs two things configured on each end: a source and a destination. That is fine for 2 sites and miserable for 50. A full mesh of n sites needs n(n-1)/2 tunnels, and even a plain hub-and-spoke needs a distinct tunnel interface on the hub for every spoke. Worse, the destination must be a fixed, known IP address, which rules out branches on DHCP broadband without extra machinery.
What you actually want is one tunnel interface per router that can talk to any number of peers, with the peer addresses learned at runtime instead of typed into the config. That is exactly what DMVPN builds, and each of its three components solves one specific part of the problem.
Ingredient 1: mGRE, One Interface for Many Peers
Multipoint GRE is regular GRE encapsulation with the destination removed from the configuration. The interface has a source and a mode, nothing else:
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source Ethernet0/1
tunnel mode gre multipoint
tunnel key 100Think of the overlay subnet (10.0.0.0/24 here) as one big virtual LAN that all DMVPN routers share. On a real LAN, when a host wants to send a frame it uses ARP to resolve an IP address into a MAC address. An mGRE interface has the same problem in a different costume: to send a GRE packet to overlay address 10.0.0.3, the router must learn which underlay address (Cisco docs call it the NBMA address) that tunnel IP lives at. GRE cannot answer that question. Something has to play the role ARP plays on Ethernet.
Ingredient 2: NHRP, the Overlay's Address Book
NHRP (Next Hop Resolution Protocol) is that something. One router, the hub, is designated the Next Hop Server (NHS), and every spoke is configured with the hub's overlay address plus a static map telling it how to reach the hub in the underlay:
interface Tunnel0
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.1At boot, each spoke sends the hub an NHRP Registration Request: "overlay 10.0.0.2 lives at underlay 198.51.100.1." Here is that exchange from the spoke's debug, triggered by bouncing the tunnel:
*Jul 11 18:39:31.271: NHRP: Send Registration Request via Tunnel0 vrf: global(0x0), packet size: 106
*Jul 11 18:39:31.274: NHRP: Receive Registration Reply via Tunnel0 vrf: global(0x0), packet size: 126
*Jul 11 18:39:31.274: %DMVPN-5-NHRP_NHS_UP: Tunnel0: Next Hop Server : (Tunnel: 10.0.0.1 NBMA: 203.0.113.1) for (Tunnel: 10.0.0.2 NBMA: 198.51.100.1) is UPThe hub builds its cache purely from these registrations. Notice the attribute column: the spokes appear as D (dynamic), meaning the hub was never configured with either of them:
HUB# show dmvpn
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 DLater, when a spoke needs to reach another spoke directly, it sends the hub an NHRP Resolution Request ("who holds 10.0.0.3?") and caches the answer for a few minutes. Registration populates the hub; resolution queries it on demand. The two message types, plus the Phase 3 redirect, get their own article: the NHRP deep dive.
One myth worth killing early: the ip nhrp network-id does not need to match between routers. It is locally significant. What must match are the NHRP authentication string and the GRE tunnel key, and both fail in instructive ways covered in troubleshooting DMVPN.
Ingredient 3: A Routing Protocol, Because NHRP Only Knows Endpoints
NHRP resolves tunnel addresses. It knows nothing about the LANs behind each router. If SPOKE2's users sit on 10.0.2.0/24, no NHRP message will ever advertise that prefix. This division of labor trips people up constantly, so it is worth stating plainly: NHRP maps overlay addresses to underlay addresses; the routing protocol maps LAN prefixes to overlay next hops. You need both.
So a routing protocol runs across the tunnel exactly as it would on a LAN. In our lab it is EIGRP named mode, and the spoke learns the other sites' prefixes with next hops on the tunnel subnet:
SPOKE1# show ip route eigrp
D 10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:01:58, Tunnel0
D 10.0.100.0/24 [90/76800640] via 10.0.0.1, 00:02:04, Tunnel0
D 192.168.99.0/24 [90/77312000] via 10.0.0.1, 00:02:04, Tunnel0The multicast piece deserves a sentence. EIGRP hellos and OSPF hellos are multicast, and an mGRE interface has no broadcast capability. The ip nhrp map multicast 203.0.113.1 line on spokes (and the dynamic equivalent on the hub, which is the default for mGRE on modern IOS XE) tells the router to replicate multicast packets as unicast GRE to those peers. Forget it and your routing protocol never forms an adjacency, even though pings work. Routing design choices over the overlay are covered in routing over DMVPN.
Watching the Three Work Together
Here is the sequence when a user behind SPOKE1 (10.0.1.0/24) sends a packet to a user behind SPOKE2 (10.0.2.0/24) in a Phase 3 network, with each component doing its one job:
First, the RIB (routing protocol's contribution) says 10.0.2.0/24 is reachable via 10.0.0.1, so the first packets go to the hub. The hub forwards them to SPOKE2 and simultaneously notices it relayed traffic between two spokes on the same tunnel, so it sends SPOKE1 an NHRP redirect (NHRP's contribution). SPOKE1 resolves 10.0.2.0/24, learns it lives at underlay 192.0.2.1, and installs a shortcut. From then on, mGRE (encapsulation's contribution) wraps packets directly to 192.0.2.1 with no hub in the path. Two consecutive traceroutes from the lab show the switch happening:
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 *And the NHRP cache afterward shows both kinds of entry side by side: the static map to the hub that never expires, and the dynamic shortcut that will age out if unused:
SPOKE1# show ip nhrp
10.0.0.1/32 via 10.0.0.1
Tunnel0 created 00:02:25, never expire
Type: static, Flags: used
NBMA address: 203.0.113.1
10.0.2.0/24 via 10.0.0.3
Tunnel0 created 00:00:09, expire 00:09:50
Type: dynamic, Flags: router used rib nho
NBMA address: 192.0.2.1How much of that machinery activates depends on the DMVPN phase. In Phase 1 the spokes run plain point-to-point GRE and everything transits the hub forever; in Phase 3 the redirect-and-shortcut dance above happens automatically. The phases are compared with live captures in Phase 1 vs Phase 2 vs Phase 3.
What About Encryption?
Nothing above is encrypted. GRE is an envelope, not a safe. The fourth, optional ingredient is an IPsec profile applied to the tunnel interface with tunnel protection, which wraps every GRE packet in ESP negotiated by IKEv2. The elegant part is that NHRP, the routing protocol, and mGRE are completely unaware of it; the configuration and verification are identical with or without encryption. The full IKEv2 build with real SA output is in securing DMVPN with IPsec profiles.
What the Underlay Must Provide (and What It Must Not Do)
Because DMVPN is an overlay, it is easy to forget that it makes demands on the transport underneath. They are few but absolute. Every router's tunnel source address must be reachable from every other router's tunnel source; for spoke-to-spoke tunnels specifically, that means spokes need direct reachability to each other's public addresses, not just to the hub. The transport must pass GRE (IP protocol 47) or, in encrypted designs, ESP and IKE (UDP 500/4500); a provider or firewall that filters protocol 47 produces the same maddening silent-drop symptoms as a tunnel key mismatch. And the underlay MTU budget must absorb the encapsulation overhead, which is why every tunnel in this cluster carries ip mtu 1400 and ip tcp adjust-mss 1360.
NAT deserves its own sentence. A spoke behind NAT registers whatever source address its packets arrive from, and NHRP on modern IOS XE handles this with NAT extensions (the hub records both the claimed and observed NBMA address, and show dmvpn flags the peer with N). Hub behind NAT is much worse and generally a design smell: spokes bootstrap to a static map, and that map must be the hub's post-NAT address. The rule of thumb is that spoke-side NAT is survivable and hub-side NAT should be engineered away.
One recursion trap rounds out the underlay contract. The router must not learn a route to the tunnel destination through the tunnel itself, or the interface flaps with %TUN-5-RECURDOWN. It happens the moment someone advertises the underlay subnets into the overlay routing protocol. The clean fix in production is a front-door VRF for the transport interface, so underlay and overlay routing tables cannot see each other at all; the quick fix in a lab is simply never advertising underlay prefixes into the overlay IGP.
Where DMVPN Sits Among the Alternatives
It helps to place DMVPN on the map of Cisco VPN technologies, because exam blueprints love the comparison. Against static site-to-site IPsec (crypto maps or SVTIs), DMVPN wins on operational scale: one interface per router versus one tunnel per peer, plus dynamic spoke addresses for free. Against GETVPN, the trade is topology: GETVPN encrypts traffic on an existing any-to-any WAN (like MPLS) with no tunnels at all, while DMVPN builds the any-to-any topology itself over an untrusted transport, which is why GETVPN lives inside private WANs and DMVPN lives on the internet. FlexVPN, Cisco's IKEv2-native framework, overlaps DMVPN heavily and shares NHRP for its spoke-to-spoke machinery; new greenfield designs sometimes start there, but the installed base, tooling, and exam weight still belong to DMVPN. And SD-WAN is, bluntly, DMVPN's ideas with a controller: overlay tunnels, central registration, dynamic path selection. Understanding this stack of trade-offs is most of the "choose the right VPN" question in GRE vs IPsec vs GRE-over-IPsec.
The Mental Model That Makes DMVPN Easy
Treat the overlay as an Ethernet LAN and map each DMVPN component onto its LAN equivalent. The tunnel subnet is the LAN segment. The underlay NBMA address is the MAC address. NHRP is ARP, with the hub acting as an answering service instead of broadcast. The routing protocol is just the routing protocol, doing exactly what it does on any LAN. And a Phase 3 shortcut is the moment two hosts stop asking the router to relay and start talking directly.
The analogy even predicts the failure modes. ARP broken means reachable IP but no delivery; NHRP broken means tunnel up but state stuck in NHRP. Wrong VLAN tag means silent drops; wrong tunnel key means exactly the same thing. When you troubleshoot DMVPN (walked through failure by failure in troubleshooting DMVPN), you are really just asking which LAN-equivalent layer broke.
Key Takeaways
DMVPN is mGRE plus NHRP plus a routing protocol, and each answers one question the others cannot. mGRE provides a single tunnel interface with no fixed destination. NHRP resolves overlay addresses to underlay addresses the way ARP resolves IPs to MACs, with spokes registering to a hub instead of broadcasting. The routing protocol distributes LAN prefixes, which NHRP never carries. Multicast-to-unicast mapping is what lets routing adjacencies form over the overlay at all, and IPsec bolts on underneath without changing any of it. Build the full thing yourself with the Phase 3 configuration walkthrough, or go back up to the DMVPN complete guide for the whole cluster.
