Lab Objective
Extend the basic DMVPN hub configured in an earlier lab to include a second spoke, configure NHRP shortcut switching and redirect on the hub and spokes, and verify traffic between two spokes initially traverses the hub but then shifts to a direct spoke-to-spoke tunnel.
Lab Purpose
The basic DMVPN lab covered earlier in this series established spoke registration with the hub, but all traffic between spokes would still be forced through the hub, doubling latency and consuming hub bandwidth unnecessarily. Phase 3 DMVPN adds NHRP redirect and shortcut messages that let spokes discover each other's actual location and build a direct tunnel on demand.
Lab Topology
Hub ---- Tunnel0 (mGRE): 172.16.200.1/24
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24
Spoke1's LAN: 192.168.11.0/24
Spoke2's LAN: 192.168.12.0/24
(both spokes already registered with the
hub as in the earlier basic DMVPN lab)Task 1: Add Spoke2 to the Existing DMVPN Cloud
Configure Spoke2's tunnel interface with NHRP registration toward the hub, matching Spoke1's existing configuration.
Task 2: Enable NHRP Redirect on the Hub
Configure the hub's tunnel interface to send NHRP redirect messages when it detects suboptimal traffic between two spokes.
Task 3: Enable NHRP Shortcut Switching on Both Spokes
Configure each spoke's tunnel interface to act on redirect messages by building a direct shortcut tunnel.
Task 4: Generate Traffic Between the Two Spoke LANs
Generate traffic from Spoke1's LAN toward Spoke2's LAN and observe the initial path through the hub.
Task 5: Verify the Direct Spoke-to-Spoke Tunnel Forms
After the initial traffic triggers the redirect, confirm subsequent traffic uses a direct spoke-to-spoke path instead.
Solution and Verification
Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip address 172.16.200.3 255.255.255.0
Spoke2(config-if)# tunnel source gigabitethernet0/1
Spoke2(config-if)# tunnel mode gre multipoint
Spoke2(config-if)# ip nhrp network-id 1
Spoke2(config-if)# ip nhrp nhs 172.16.200.1 nbma [hub's public IP]Hub(config)# interface tunnel0
Hub(config-if)# ip nhrp redirect
-- The hub monitors traffic flowing through
-- it and sends an NHRP redirect message to
-- the source spoke whenever it notices
-- traffic destined for another spoke's
-- network taking the longer hub-relayed pathSpoke1(config)# interface tunnel0
Spoke1(config-if)# ip nhrp shortcut
Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip nhrp shortcut
-- "shortcut" tells each spoke to actually
-- act on a received redirect by initiating
-- NHRP resolution for the other spoke's
-- real address and building a direct tunnelSpoke1-LAN-PC> ping 192.168.12.10
-- Initial packets traverse via the hub:
Hub# show ip nhrp traffic
-- (redirect messages sent counter
-- increments as the hub notices this
-- suboptimal path)Spoke1# show ip nhrp
172.16.200.3/32 via 172.16.200.3
Tunnel0 created, expire 01:59:50
Type: dynamic, Flags: router rib nho
NBMA address: [Spoke2's actual public IP]
-- A new dynamic NHRP entry appeared for
-- Spoke2, learned via the shortcut
-- resolution process rather than only
-- being known through the hubSpoke1-LAN-PC> ping 192.168.12.10
-- Continued/subsequent traffic now takes
-- a direct spoke-to-spoke path
Spoke1# show ip nhrp shortcut
172.16.200.3/32 via 172.16.200.3
Tunnel0 created, expire 01:59:20
Type: shortcut, Flags: router rib
-- Explicitly marked as "shortcut" type,
-- confirming this is a dynamically
-- established direct tunnel rather than
-- traffic still relayed through the hubKey Takeaway
Phase 3 DMVPN's ip nhrp redirect (configured on the hub) and ip nhrp shortcut (configured on the spokes) work as a matched pair — the hub notices inefficient hub-relayed traffic and suggests a better path, while spokes actually build that direct tunnel in response — and this shortcut behavior is precisely what distinguishes Phase 3 from the basic hub-and-spoke-only DMVPN configured in an earlier lab, where all inter-spoke traffic was permanently forced through the hub with no mechanism to improve it.