← All posts
ccnp-svpn

DMVPN - Dynamic Multipoint VPN

January 20, 2025·9 min read

Deep dive into DMVPN architecture, phases, and configuration. Understand how hub-and-spoke and spoke-to-spoke tunnels work dynamically using NHRP and mGRE.

The Problem With Traditional VPNs

In a classic point-to-point IPsec VPN deployment, every pair of sites that need to communicate requires its own dedicated tunnel. A network with 50 branch offices connecting back to headquarters needs 49 tunnels on the hub alone. If branches need to talk to each other directly, that number explodes to n(n-1)/2 tunnels — and each one must be statically configured with the peer's IP address.

This doesn't scale. It's also fragile: if a branch gets a new IP from its ISP, you're manually reconfiguring tunnels.

DMVPN — Dynamic Multipoint VPN — solves this by combining three technologies to create a scalable, dynamic tunnel infrastructure that requires minimal configuration on the hub and almost none on the spokes.

Core Components

mGRE — Multipoint GRE

Standard GRE tunnels are point-to-point: one source, one destination. Multipoint GRE allows a single tunnel interface on the hub to accept connections from any number of spoke routers dynamically. The hub doesn't need a separate tunnel interface per spoke.

NHRP — Next Hop Resolution Protocol

NHRP is the glue that makes dynamic spoke-to-spoke tunnels possible. It functions like an ARP for the DMVPN overlay network:

  • Each spoke registers its NBMA address (public IP) with the hub upon boot
  • The hub maintains an NHRP database mapping tunnel IP → physical IP
  • When Spoke A wants to reach Spoke B, it queries the hub via NHRP to resolve Spoke B's real IP
  • Once resolved, Spoke A builds a direct tunnel to Spoke B — bypassing the hub

IPsec

mGRE handles the tunnel mechanics; IPsec provides encryption. In a production DMVPN deployment, an IPsec profile is applied to the tunnel interface. The combination of mGRE + NHRP + IPsec gives you a scalable, encrypted overlay network.

Hub-and-Spoke Architecture

All spoke routers form permanent tunnels to the hub. The hub acts as the NHRP server (NHS — Next Hop Server). Spokes are NHRP clients that register with the hub when they come online.

The hub always has a static public IP. Spokes can have dynamic IPs — they register their current public IP at boot time, so the hub always knows how to reach them even if their address changes.

DMVPN Phases

DMVPN has three phases, each adding more capability:

Phase 1 — Hub-and-Spoke Only

All traffic flows through the hub. Spoke-to-spoke communication is only possible by routing through the hub (hub decapsulates and re-encapsulates). Simple but creates a bottleneck. The hub must summarize or use host routes.

Phase 2 — Direct Spoke-to-Spoke

Spokes can build on-demand direct tunnels to each other using NHRP resolution. When Spoke A sends traffic destined for Spoke B, the hub provides a redirect (NHRP redirect message). Spoke A queries NHRP, resolves Spoke B's IP, and builds a direct mGRE tunnel.

Limitation: Routing protocols cannot summarize routes at the hub — all spokes must be able to see each other's exact routes. This means no summarization on the hub, which doesn't scale well for large deployments.

Phase 3 — Hierarchical and Optimized

Introduces NHRP shortcut switching on the hub. Spokes use NHRP traffic indication + shortcut messages to dynamically build direct tunnels. Unlike Phase 2, the hub can summarize routes while still enabling direct spoke-to-spoke paths. This scales much better for large networks with hundreds of spokes.

Phase 3 is the recommended deployment model for most enterprise DMVPN networks.

Spoke-to-Spoke Tunnel Lifecycle

  1. Spoke A sends a packet destined for Spoke B's tunnel IP
  2. The packet initially routes through the hub
  3. The hub sends an NHRP redirect back to Spoke A
  4. Spoke A sends an NHRP resolution request to the hub, asking for Spoke B's NBMA IP
  5. Hub forwards the resolution request to Spoke B
  6. Spoke B responds with its NBMA (public) IP
  7. Spoke A builds a direct mGRE + IPsec tunnel to Spoke B
  8. Subsequent traffic flows directly — the hub is no longer in the path
  9. The spoke-to-spoke tunnel has a hold-time timer and is torn down when idle

Configuration Overview

Hub Tunnel Interface

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 ip nhrp network-id 1
 ip nhrp authentication DMVPN_KEY
 ip nhrp map multicast dynamic
 tunnel key 100

Spoke Tunnel Interface

interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 ip nhrp network-id 1
 ip nhrp authentication DMVPN_KEY
 ip nhrp nhs 10.0.0.1 nbma <HUB_PUBLIC_IP> multicast
 tunnel key 100

The key differences on the spoke: ip nhrp nhs points to the hub's tunnel IP and specifies the hub's real (NBMA) IP. The multicast keyword allows routing protocol hellos to reach the hub.

Key Takeaways

  • DMVPN replaces hundreds of static tunnels with a single scalable overlay
  • The hub needs minimal config; spokes auto-register via NHRP
  • Phase 1 = hub-and-spoke only; Phase 2 = direct spokes (no summarization); Phase 3 = direct spokes with summarization
  • IPsec is layered on top of mGRE to encrypt the overlay
  • NHRP resolution is what makes dynamic spoke-to-spoke tunnels possible without pre-configuration
© 2025 Karan Belani — Network Engineer
AboutCertsBlogContact