DMVPN Phase 2 and Phase 3: Spoke-to-Spoke Tunnels, NHRP, and Routing Design

March 13, 2026·10 min read

Overview

DMVPN (Dynamic Multipoint VPN) solves the hub-and-spoke VPN scaling problem: in a traditional hub-and-spoke, all spoke-to-spoke traffic hairpins through the hub, doubling latency and consuming hub bandwidth. DMVPN uses mGRE tunnels and NHRP to allow spokes to discover each other's real IP addresses and build direct tunnels on demand — without any static configuration change at the hub.

Phase 1 routes all traffic through the hub. Phase 2 allows spoke-to-spoke shortcuts but has routing constraints. Phase 3 removes those constraints using NHRP redirects and is the recommended design for most deployments.

Phase 2 vs Phase 3 Comparison

Feature	Phase 2	Phase 3
Spoke-to-spoke tunnels	Yes — triggered by traffic	Yes — triggered by NHRP redirect
NHRP mechanism	Resolution (spoke asks hub for peer NBMA)	Redirect (hub tells spoke to go direct)
Routing on hub	Must NOT summarize — spokes need specific routes	Can summarize — hub only needs aggregate
Split horizon	Must disable on hub tunnel interface	Not required — NHRP redirect handles it
Scalability	Limited — hub route table grows with spoke count	Better — hub carries summaries only
Recommended for	Small deployments, ≤30 spokes	Production — any size

Topology

Hub Configuration

cisco

! Phase 3 hub — tunnel interfaceinterface Tunnel0 ip address 10.10.0.1 255.255.255.0 no ip redirects ip nhrp authentication DMVPN-KEY ip nhrp network-id 1 ip nhrp redirect ! "ip nhrp redirect" is the Phase 3 key — hub tells spokes to go direct tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 100 tunnel protection ipsec profile DMVPN-IPSEC-PROF! EIGRP on hub — summary only, not specific spoke routesrouter eigrp 100 network 10.10.0.0 0.0.0.255 network 10.0.0.0 0.0.255.255 no auto-summary

Note: With OSPF on Phase 2, you must set the tunnel interface network type to point-to-multipoint or disable split horizon. With EIGRP on Phase 3, neither workaround is needed.

Spoke Configuration

cisco

! Spoke — same tunnel config on all spokes, only NBMA source differsinterface Tunnel0 ip address 10.10.0.2 255.255.255.0 ! Change .2 to .3, .4 etc. per spoke ip nhrp authentication DMVPN-KEY ip nhrp network-id 1 ip nhrp nhs 10.10.0.1 nbma 203.0.113.1 multicast ! NHS = hub tunnel IP, NBMA = hub public/outside IP ip nhrp shortcut ! "ip nhrp shortcut" is the Phase 3 key on spokes — installs NHRP-learned routes tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 100 tunnel protection ipsec profile DMVPN-IPSEC-PROF! EIGRP on spokerouter eigrp 100 network 10.10.0.0 0.0.0.255 network 10.1.0.0 0.0.255.255 ! Advertise local LAN

IPsec Profile (same on hub and all spokes)

cisco

crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 lifetime 86400crypto isakmp key DMVPN-IPSEC-PSK address 0.0.0.0 0.0.0.0crypto ipsec transform-set DMVPN-TSET esp-aes 256 esp-sha256-hmac mode transport ! Transport mode for mGRE — tunnel mode would double-encapsulatecrypto ipsec profile DMVPN-IPSEC-PROF set transform-set DMVPN-TSET set isakmp-profile DMVPN-ISAKMP

NHRP Redirect Flow (Phase 3)

bash

# Step 1: Spoke-1 sends traffic destined for Spoke-2's LAN# First packet goes Hub → Hub forwards, sends NHRP Redirect to Spoke-1# "Hey, go directly to 198.51.100.20 for 10.10.0.3"# Step 2: Spoke-1 sends NHRP Resolution Request to Hub# Hub replies with Spoke-2's NBMA IP# Step 3: Spoke-1 builds direct IPsec/GRE tunnel to Spoke-2# All subsequent packets travel Spoke-1 ↔ Spoke-2 directly# Verify shortcut table on spoke:R-SPOKE1# show ip nhrp via 10.10.0.3# Look for "via 198.51.100.20" — that's the spoke-to-spoke shortcutR-SPOKE1# show dmvpn detail# Type: Spoke, Tunnel interface: Tunnel0# NHRP entries: should show peer entries for other spokes

HUB — show dmvpn detail & show ip nhrp
HUB# show dmvpn detail
======================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type: Hub, NHRP Peers: 3, NHS: local
Tunnel: source Gi0/0, mode gre multipoint, key 100, IPSEC profile: DMVPN-IPSEC-PROF
======================================================================
# Ent  Peer NBMA Addr       Peer Tunnel Addr    State   UpDn Tm    Attrb
-----  ---------------     ----------------    ------  ---------  -----
    1  198.51.100.10    10.10.0.2           UP      02:31:14   D
    1  198.51.100.20    10.10.0.3           UP      02:31:11   D
    1  198.51.100.30    10.10.0.4           UP      02:08:44   D
Attrb: D=Dynamic (spoke registered) T=Temporary (shortcut)
SPOKE-1# show ip nhrp via 10.10.0.3 detail
10.10.0.3/32 via 10.10.0.3
  Tunnel0 created 00:04:22, expire 01:55:38
  Type: dynamic, Flags: router nhop unique
  NBMA address: 198.51.100.20  <-- Phase 3 shortcut installed directly to Spoke-2
  Shortcut created by: hub redirect (ip nhrp redirect on hub)
SPOKE-1# show ip route 10.10.20.0 255.255.255.0
D     10.10.20.0/24 [90/27008000] via 10.10.0.3, 00:04:15, Tunnel0
                  <-- EIGRP route via spoke-to-spoke shortcut, not via hub (10.10.0.1)
Phase 3 key difference
ip nhrp redirect
on HUB — sends NHRP redirect
telling spokes to go direct
Spoke-1 → Spoke-2 path
Direct shortcut
NBMA 198.51.100.20
bypasses hub entirely
Shortcut flag
Attrb: T (Temp)
expires + refreshes
while traffic flows

Real-World Scenario

The situation: A 45-spoke retail DMVPN was deployed using Phase 2 with EIGRP. POS traffic between two adjacent store spokes was taking 80ms because it hairpinned through the HQ hub. Direct path between the stores is 8ms.

Symptoms observed:

traceroute from Spoke-1 to Spoke-2 LAN shows Hub as middle hop
show ip nhrp on spokes shows only the hub entry — no spoke-to-spoke shortcuts forming
EIGRP is running on the hub tunnel with split-horizon enabled (default)

Root cause: Split-horizon on the hub's EIGRP tunnel interface was preventing spoke routes from being re-advertised back out the same interface. Spokes never learned each other's specific prefixes, so NHRP resolution requests couldn't complete.

Fix (Phase 2 workaround — or upgrade to Phase 3):

cisco

! Option A — Phase 2 fix: disable split horizon on hub tunnelHUB(config-if)# interface Tunnel0HUB(config-if)#  no ip split-horizon eigrp 100! Option B — upgrade to Phase 3 (recommended):! On hub:HUB(config-if)#  ip nhrp redirect! On all spokes:SPOKE(config-if)#  ip nhrp shortcut

Verification:

cisco

SPOKE-1# show ip nhrp detail! Phase 3: should show entries for all known spokes with their NBMA IPs! "Flags: router nhop" = shortcut route installedSPOKE-1# show ip route 10.2.0.0! Should show via Tunnel0, nexthop = Spoke-2 tunnel IP! NOT via hub tunnel IP

Troubleshooting

Spokes register to hub but spoke-to-spoke shortcuts never form

Symptom: show dmvpn shows spokes registered, but traffic between spokes always goes through hub. show ip nhrp only shows hub entry.

Cause (Phase 3): Missing ip nhrp redirect on hub or ip nhrp shortcut on spokes.

Fix:

cisco

HUB(config-if)# interface Tunnel0HUB(config-if)#  ip nhrp redirectSPOKE(config-if)# interface Tunnel0SPOKE(config-if)#  ip nhrp shortcut

NHRP registration fails — spoke can't reach hub

Symptom: show dmvpn shows spoke in IKE or IPSEC state, never UP. debug nhrp shows registration requests sent but no reply.

Cause: IPsec phase 1 (IKE) failing — mismatched pre-shared key, IKE policy mismatch, or NAT device not passing UDP 500/4500.

Fix:

cisco

SPOKE# debug crypto isakmpSPOKE# debug crypto ipsec! Look for: "ISAKMP: No pre-shared key found" or "atts not acceptable"! Check: crypto isakmp key matches exactly on hub and spoke! Check: UDP 500 and 4500 permitted through any NAT/firewall between sites

Spoke routes flap after shortcut tunnel forms

Symptom: Spoke-to-spoke connection established, then routes appear/disappear every 2 minutes.

Cause: NHRP hold time too short, or NHRP cache expiring before keepalives refresh it.

Fix:

cisco

! Increase NHRP hold time (default 7200 seconds — check both sides match)interface Tunnel0 ip nhrp holdtime 600 ! Also increase EIGRP hello/hold timers on tunnel interface ip hello-interval eigrp 100 20 ip hold-time eigrp 100 60

DMVPN Phase 3 Deployment Checklist

ip nhrp redirect on hub tunnel interface — this is the only Phase 3 config difference on the hub
ip nhrp shortcut on all spoke tunnel interfaces — installs NHRP-learned routes in FIB
IPsec mode is transport for mGRE (not tunnel — double encapsulation causes fragmentation)
tunnel key matches across hub and all spokes — mismatches cause silent drops
NHRP authentication string identical on hub and all spokes — ip nhrp authentication
Hub advertises a summary covering all spoke LANs — spokes use it until shortcut forms
UDP 500 and 4500 permitted through any NAT/firewall in the underlay path
NHRP hold time consistent — ip nhrp holdtime must be longer than the routing protocol dead interval
Verify shortcuts forming with show ip nhrp after first cross-spoke traffic
show dmvpn detail on hub shows all spokes in UP state before cutover