Back to DMVPN Labs

DMVPN Introduction: Definition, Architecture and Phases

Understand why DMVPN exists, how its technologies work together, what changes between Phase 1, Phase 2 and Phase 3, and when the design is appropriate for an enterprise WAN.

DMVPNmGRENHRPIPsecPhase 1–3

What Is DMVPN?

Dynamic Multipoint Virtual Private Network (DMVPN) is a Cisco overlay architecture that connects a central hub to many branch spokes through a routed transport such as the Internet, MPLS, or another IP WAN. It combines multipoint GRE, NHRP, a routing protocol, and optional IPsec protection.

DMVPN is not a single protocol. It is a design framework in which each technology solves a different problem: GRE creates the overlay, NHRP discovers transport endpoints, routing exchanges private prefixes, and IPsec protects the traffic.

OverlaymGRE tunnel
Mapping serviceNHRP
ReachabilityDynamic routing
ProtectionIPsec profile

In This Lesson

  1. Why DMVPN is required
  2. Read the topology
  3. Understand the components
  4. Compare all three phases
  5. Evaluate use cases
  6. Check design requirements
  7. Follow the lab path
  8. Review common questions

Why Do We Need DMVPN?

A traditional point-to-point tunnel design requires a separate tunnel and peer definition for each relationship. As branches increase, hub configuration, addressing, crypto policy, and operational effort grow quickly. A full mesh also requires every site to know every other site's transport address in advance.

Reusable spoke template

A new branch can use the same logical configuration pattern and register its current NBMA address with the hub.

Fewer hub interfaces

One mGRE tunnel can represent many peers instead of creating one tunnel interface for every branch.

Dynamic peer discovery

NHRP resolves a tunnel address to the peer's underlay address when direct communication is required.

Optional path optimization

Phase 2 and Phase 3 can remove the hub from steady-state spoke-to-spoke forwarding.

Read the Hub-and-Spoke Topology

A hub router using three separate VPN tunnels to connect to three spoke sites
Traditional tunnel design. The hub needs a separate tunnel for every spoke. Adding more branches means adding more tunnel configuration at the hub.
DMVPN hub-and-spoke design with one hub site and three spoke sites connected through a shared DMVPN cloud
DMVPN hub-and-spoke design. The routers share a multipoint tunnel network. Spokes register with the hub and can create direct paths when the selected DMVPN phase allows it.
Two address spaces:

The NBMA address identifies where a router is reachable on the transport network. The tunnel address identifies the router inside the overlay. NHRP maintains the relationship between them.

Core DMVPN Components

ComponentResponsibilityKey point
mGREAllows one tunnel interface to reach multiple dynamic destinationsIt provides encapsulation, not encryption
NHRPMaps overlay tunnel addresses to underlay NBMA addressesThe hub commonly acts as the NHS
Routing protocolAdvertises branch LAN prefixes across the overlayNext-hop behavior determines the phase workflow
IPsecProvides confidentiality, integrity, and peer authenticationApplied with a tunnel-protection profile
UnderlayRoutes packets between tunnel sources and destinationsMust work before DMVPN can work

DMVPN Phase 1, Phase 2 and Phase 3

PhaseTunnel designSpoke-to-spoke pathRouting behaviorBest fit
Phase 1Hub mGRE; spoke point-to-point GREAlways through hubHub remains the next hopSimple centralized forwarding
Phase 2mGRE on hub and spokesDirect after NHRP resolutionRemote spoke must remain the route next hopSmaller networks needing direct paths
Phase 3mGRE plus redirect and shortcutInitial packet via hub, then directHub can advertise summaries or a defaultMore scalable branch overlays
The central difference:

Phase 2 depends on the routing table already pointing to the remote spoke. Phase 3 can keep the hub as the routing next hop and use NHRP redirect and shortcut to optimize the forwarding plane.

Common DMVPN Use Cases

  • Connect many branch offices to one or two regional hubs through Internet or private IP transport.
  • Allow voice, replication, or application traffic to use direct branch-to-branch paths when required.
  • Support spokes whose public transport address may change while the hub retains a stable address.
  • Protect GRE and routing traffic with a scalable IPsec tunnel profile.
  • Build a migration or backup overlay without defining a static tunnel for every site pair.
When another design may fit better: Use ordinary site-to-site IPsec for a very small fixed topology, SD-WAN when centralized application policy and multi-transport orchestration are primary requirements, or provider-managed L3VPN when the carrier should own the WAN routing service.

Technical Requirements and Design Checks

Reachable underlayEvery tunnel endpoint needs an underlay route to its required peers.
Stable hub addressSpokes must reliably reach the hub NBMA address used in their NHRP mapping.
Unique overlay addressingEach router needs an unambiguous tunnel address and branch prefixes.
Routing compatibilityEIGRP, OSPF, BGP, or static routing must match the selected phase behavior.
MTU planningAccount for GRE and IPsec overhead and tune TCP MSS when necessary.
Security policySelect IKE/IPsec algorithms, authentication, keys, and redundancy deliberately.

Recommended Learning Path

  1. Build point-to-point GRE and understand the underlay/overlay boundary.
  2. Build Phase 1 and prove hub-transit forwarding.
  3. Build Phase 2 and observe dynamic spoke-to-spoke resolution.
  4. Build Phase 3 and separate summarized routing from optimized forwarding.

Frequently Asked Questions

Is DMVPN a VPN protocol?

DMVPN is an architecture combining multiple technologies. mGRE builds the overlay, NHRP supplies mappings, routing advertises private prefixes, and IPsec optionally supplies security.

Does DMVPN require IPsec?

The GRE and NHRP overlay can operate without IPsec, but untrusted transports normally require IPsec to protect confidentiality, integrity, and peer identity.

Which phase should a new design use?

Phase 3 is generally preferred when route summarization and scalable direct forwarding are important. The correct choice still depends on platform support, routing design, operational familiarity, and migration constraints.