Point-to-point IPsec tunnels scale like full-mesh iBGP: fifty branches to one hub is fifty tunnel configurations on the hub, and branch-to-branch traffic either hairpins through the hub or demands 1,225 more tunnels. Dynamic Multipoint VPN dissolves the problem with one idea: make the tunnel interface multipoint, and resolve destinations dynamically. Every router — hub and spokes alike — has a single mGRE interface with a single tunnel address in one overlay subnet; what varies is knowledge of who lives where, and that knowledge is NHRP's department.
The three components
- mGRE — a GRE interface with no fixed destination; it can encapsulate to any peer, once it learns the peer's real (NBMA) address.
- NHRP — the Next Hop Resolution Protocol, the overlay's address book. Spokes register their tunnel-address→public-address mapping with the hub (the NHRP server) at boot; anyone needing to reach a tunnel address queries the hub for the current mapping. Registration is also what makes spokes behind NAT and DHCP workable: the hub learns whatever address the spoke arrives from.
- IPsec profiles — applied to the tunnel interface, encrypting whatever mGRE sends; certificates or wildcard PSKs let any spoke authenticate without per-peer hub configuration.
The phases: where the traffic flows
DMVPN's design generations are named phases, and the phase decides both traffic patterns and routing design. Phase 1: hub-and-spoke only — spokes' mGRE speaks solely to the hub; simple, and all spoke-to-spoke traffic transits the hub. Phase 2: spokes resolve each other via NHRP and build direct tunnels, but the routing protocol must preserve each spoke's next hop unchanged (no summarisation at the hub) — operationally brittle, and effectively obsolete. Phase 3: the current answer — traffic initially follows the routed path through the hub; the hub, forwarding spoke-to-spoke traffic, sends an NHRP redirect to the ingress spoke; the spoke resolves the far end, installs an NHRP shortcut over the routing table, and subsequent packets flow direct. Because shortcuts override routing, the hub can summarise aggressively — even a single default toward the spokes — and the overlay still finds direct paths.
! spoke, phase 3:interface tunnel0 ip address 172.31.0.11 255.255.255.0 tunnel mode gre multipoint tunnel source gi0/0 ip nhrp network-id 1 ip nhrp nhs 172.31.0.1 nbma 203.0.113.10 multicast ip nhrp shortcut! hub adds: ip nhrp redirect tunnel protection ipsec profile PROT
Routing and verification
A routing protocol runs over the tunnel subnet as if it were one LAN: EIGRP (with stub spokes — the design the EIGRP book's final chapter described) or OSPF, or per-spoke BGP at large scale. Multicast over the overlay reaches only NHRP-registered peers flagged for it, which is why the nhs line carries the multicast keyword. Verification is three commands deep: show dmvpn (each peer's NBMA address, tunnel address and state — spokes show the hub static, dynamic entries appear as shortcuts form), show ip nhrp (the mappings and their origin: static, registered, or shortcut), and the IPsec counters from the previous chapter, since every DMVPN fault is ultimately either an NHRP fault (registration missing, resolution failing) or a plain IPsec fault wearing DMVPN clothing.
Spoke1# show dmvpn | begin Peer # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb 1 203.0.113.10 172.31.0.1 UP 1d02h S 1 198.51.100.22 172.31.0.12 UP 00:02:11 D
That final D-flagged line is DMVPN's whole value visible in one row: a spoke-to-spoke tunnel that nobody configured, encrypted end to end, built because two branches had traffic for each other. SD-WAN overlays (over on the Automation shelf) industrialise exactly this pattern with central policy — DMVPN is where the mechanics are learned honestly.