DMVPN Phase 3 is considered the most flexible and scalable evolution of DMVPN. It builds upon the foundation of Phases 1 and 2, enabling full spoke-to-spoke communication with dynamic route summarization support, a major limitation in Phase 2. This phase introduces NHRP redirection and shortcuts, allowing routers to intelligently discover and switch to direct paths without having to depend on static routing updates or rigid adjacencies.

How Phase 3 Works

The core enhancement in Phase 3 is the use of NHRP Redirects and NHRP Shortcuts. When Spoke A sends a packet to Spoke B, the packet first goes through the hub (just like in Phase 1). But unlike earlier phases, the hub recognizes that it is merely a transit point and sends an NHRP Redirect message back to Spoke A. This redirect message informs Spoke A that a more efficient, direct route is available. Spoke A then initiates an NHRP Resolution Request, and the hub forwards this request to Spoke B. Once Spoke B responds with an NHRP Reply, a direct tunnel between the two spokes is established.

To enable this behavior, the hub must be configured with:

interface tunnel1
ip nhrp redirect
no ip split-horizon eigrp 100

And each spoke must be told to trust and follow the redirect with:

interface tunnel1
ip nhrp shortcut

These commands activate the automatic redirection logic and enable spokes to create direct tunnels based on dynamic next-hop resolution.

Why Phase 3 is the Preferred Model

Phase 3 eliminates many of the routing inefficiencies of Phases 1 and 2. Since spokes always point to the hub as the next hop in their routing tables, summarization is now possible. This means EIGRP only needs a single route to the hub, avoiding the bloated route tables required in Phase 2, where each spoke needed to maintain routes to every other spoke.

Additionally, because CEF adjacency tricks are no longer needed, DMVPN Phase 3 offers cleaner integration with modern routing architectures. The hub still facilitates initial communication but steps aside once it identifies itself as a transit, reducing CPU load and improving performance.

NHRP Redirect Process: Step-by-Step

  1. Spoke A (S1) registers with the hub using standard NHRP.
  2. Spoke B (S2) also registers with the hub.
  3. Spoke A sends traffic to Spoke B through the hub.
  4. The hub, recognizing it’s merely a transit point, sends an NHRP Redirect to Spoke A.
  5. Spoke A sends an NHRP Resolution Request to the hub.
  6. The hub forwards the request to Spoke B.
  7. Spoke B replies directly to Spoke A with an NHRP Reply.
  8. A spoke-to-spoke tunnel is formed, and the hub is removed from the data path.

This process is confirmed by monitoring routing tables with:

show ip route next-hop-override x.x.x.x

and observing the H (NHRP) or * next-hop override flag in the routing entry.

Scalability Across Continents

Phase 3 also allows inter-continental scalability. You can place a hub in each region (e.g., US, EU, Asia), and spokes can still establish tunnels across hubs if registered with the same NHRP network ID. Thanks to the redirection process and NHRP registration, even cross-cloud spoke-to-spoke connections are possible, essential for large global deployments.

Scalability Across Continents

Hub:

interface tunnel0
ip address 172.16.1.1/24
tunnel source f0/0
tunnel mode gre multipoint
ip nhrp network-id 123
ip nhrp map multicast dynamic
no ip split-horizon eigrp 123
ip summary-address eigrp 123 192.168.0.0/16
ip nhrp redirect
-
router eigrp 123
network 172.16.1.0
network 192.168.0.0

Spoke:

interface tunnel0
ip address 172.16.1.2/24
tunnel source f0/0
tunnel mode gre multipoint
ip nhrp network-id 123
ip nhrp nhs 172.16.1.1
ip nhrp map 172.16.1.1 100.1.1.1
ip nhrp map multicast 100.1.1.1
ip nhrp shortcut
-
router eigrp 123
network 172.16.1.0
network 192.168.0.0

High Availability with Dual Hubs

To protect against hub failure, Phase 3 supports dual-hub redundancy in two main architectures:

1. Dual-Hub Single-Cloud: Both hubs share the same tunnel interface, and spokes are registered to both using:

ip nhrp nhs Hub1
ip nhrp nhs Hub2

2. Dual-Hub Dual-Cloud: Separate tunnel interfaces and routing domains are used to isolate the hubs:

interface tunnel0
ip nhrp nhs Hub1
-
interface tunnel1
ip nhrp nhs Hub2

This design is ideal when using different ISPs or physical paths, as it allows for advanced traffic engineering and failover capabilities.

Final Thoughts

If you’re deploying DMVPN today, Phase 3 is the gold standard. It enables full dynamic tunneling, optimal routing, EIGRP summarization, and high availability without the complexity of manual mappings or the inefficiencies of earlier phases. When combined with IPSec encryption, Phase 3 offers both flexibility and security, making it the best choice for scalable enterprise VPN deployments.