DMVPN: Components and Operational Phases

1. The Challenge of Scale and the DMVPN Solution

A traditional hub-and-spoke VPN using point-to-point GRE tunnels requires a dedicated tunnel interface on the hub for each spoke. This creates two significant problems:

1. Configuration Overhead: The hub's configuration becomes enormous and complex as the network grows.
2. Inefficient Spoke-to-Spoke Traffic: If one branch office needs to communicate with another, traffic must travel up to the hub and then back down, consuming bandwidth and increasing latency. This is often called "hairpinning."

DMVPN solves both problems by creating a dynamic, non-broadcast multi-access (NBMA) network over a public transport like the internet.

To achieve this, DMVPN combines three key technologies.

2. The Core Components of DMVPN

Let's break down the building blocks of a DMVPN solution.

A. Multipoint GRE (mGRE)

The first innovation is Multipoint GRE (mGRE). Unlike a point-to-point GRE interface that requires a static tunnel destination, an mGRE interface on the hub has no configured destination. It acts as a single "one-to-many" endpoint capable of accepting connections from any number of spokes.

This single change dramatically simplifies the hub's configuration. Instead of hundreds of interface TunnelX sections, you have just one.

B. Next Hop Resolution Protocol (NHRP)

mGRE creates a new question: If the hub has no tunnel destination configured, how does it know the public (underlay) IP address of a spoke it needs to send traffic to? And more importantly, how can one spoke dynamically learn the public IP address of another spoke to build a direct tunnel?

The answer is the Next Hop Resolution Protocol (NHRP).

NHRP functions similarly to ARP. While ARP resolves a Layer 3 IP address to a Layer 2 MAC address, NHRP resolves an overlay (tunnel) IP address to an underlay (NBMA/public) IP address.

It operates on a client-server model:

• Next Hop Server (NHS): The hub router is configured as the NHS. It maintains a database—a cache of NHRP mappings.
• Next Hop Client (NHC): The spoke routers are NHCs. When a spoke comes online, it initiates a Registration Request to the hub, providing its overlay and underlay IP addresses.
• The NHS stores this mapping. Now, when any router in the DMVPN cloud needs to find the underlay address for a given overlay address, it sends a Resolution Request to the NHS.

C. IPsec Encryption

Just like the GRE tunnels we built in the last lesson, the mGRE tunnels in DMVPN are unencrypted by default. To secure them, we apply the same IPsec profile method directly to the tunnel interface.

The command tunnel protection ipsec profile <PROFILE_NAME> instructs the router to encrypt all GRE traffic (which includes the NHRP messages and the actual user data) before sending it out the physical interface. This seamlessly integrates strong security into the dynamic DMVPN fabric.

3. DMVPN Operational Phases

DMVPN is not a single entity but an evolution of a technology across three "phases." Each phase enhances the capabilities of the previous one. Understanding these phases is crucial for both design and troubleshooting.

Phase 1: Hub-and-Spoke

Phase 1 provides the basic scalable hub-and-spoke topology.

• Topology: Hub uses mGRE; spokes use standard point-to-point GRE.
• Operation: Spokes can only form a tunnel to the hub. They cannot dynamically discover other spokes.
• Traffic Flow: All traffic, including spoke-to-spoke, must hairpin through the hub. While more scalable from a configuration perspective, it's inefficient for inter-spoke communication.

Phase 2: Spoke-to-Spoke

Phase 2 introduces dynamic, direct spoke-to-spoke tunnels.

• Topology: Both the hub and all spokes use mGRE interfaces.
• Operation:
  1. Spoke-A wants to send a packet to Spoke-B. The routing table on Spoke-A points to Spoke-B's overlay IP via the hub.
  2. The first packet travels from Spoke-A to the Hub, which forwards it to Spoke-B.
  3. This triggers Spoke-A to send an NHRP Resolution Request for Spoke-B's overlay IP to the Hub.
  4. The Hub forwards the request to Spoke-B.
  5. Spoke-B responds directly to Spoke-A with its underlay IP information.
  6. Spoke-A and Spoke-B now have each other's public IPs and can build a direct, dynamic IPsec tunnel. Subsequent packets flow directly.
• Limitation: This phase has a significant drawback. If you summarize routes on the hub (a common practice for scalability), the specific next-hop information is lost, and the spoke-to-spoke tunnel mechanism breaks. All traffic reverts to hairpinning through the hub.

Phase 3: Optimized and Scalable Spoke-to-Spoke

Phase 3 is the most advanced and widely deployed version. It improves upon Phase 2 by optimizing the discovery process and, most importantly, solving the route summarization problem.

• Topology: Same as Phase 2 (mGRE everywhere).
• Operation: Phase 3 introduces two key commands: ip nhrp redirect on the hub and ip nhrp shortcut on the spokes.
  1. Spoke-A sends a packet to Spoke-B via the hub.
  2. The hub forwards the packet but also sends an NHRP Redirect message back to Spoke-A. This message tells Spoke-A, "There is a better path to this destination."
  3. This redirect triggers Spoke-A to initiate the same NHRP Resolution process as in Phase 2 to find Spoke-B's real address.
  4. A direct tunnel is formed. Because of this redirect/shortcut mechanism, the hub can advertise summarized routes, and the spokes can still resolve the specific next-hop addresses required to build direct tunnels.

This diagram perfectly illustrates the Phase 3 process:

Conclusion

You've now explored the architecture and operation of DMVPN, one of the most important and scalable VPN technologies in enterprise networking. By mastering these concepts, you've moved from static, point-to-point tunnels to a dynamic, on-demand multipoint fabric.

Key Takeaways:

• DMVPN solves the scalability issues of point-to-point IPsec VPNs using a hub-and-spoke model that can dynamically create spoke-to-spoke connections.
• The core components are mGRE for one-to-many tunnel termination, NHRP for dynamic address resolution (mapping overlay to underlay IPs), and IPsec for securing the tunnels.
• DMVPN has three phases:
  • Phase 1: Basic hub-and-spoke. All traffic hairpins through the hub.
  • Phase 2: Enables dynamic spoke-to-spoke tunnels, but is broken by route summarization.
  • Phase 3: The optimal phase. Uses NHRP redirects to support both route summarization and efficient spoke-to-spoke communication.

Preview of the Next Lesson:
We've spent the last few lessons on securing and segmenting traffic between geographically separate sites. In our next module, we'll shift our focus to virtualization and segmentation within a single device. Our first lesson will be on configuring and verifying Virtual Routing and Forwarding (VRF-lite), a technology that allows you to create multiple independent routing tables inside a single router.