Cisco 300-730 SVPN: DMVPN Phase 3: Spoke-to-Spoke Shortcut After Hub Failover

DMVPN Phase 3: Spoke-to-Spoke Shortcut After Hub Failover

Your customer runs a DMVPN Phase 3 network on Cisco IOS-XE 17.9 with two hubs (hub-a 10.0.0.1, hub-b 10.0.0.2) and 60 spokes. Each spoke has two NHS entries with priorities 10 and 20, NHRP network-id 100, and holdtime 600. Both hubs use ip nhrp redirect; every spoke uses ip nhrp shortcut. EIGRP AS 100 runs over the mGRE tunnel and each hub advertises a summary route, so all spokes appear reachable through either hub. After hub-a fails, spokes re-register to hub-b within 30 seconds and connectivity returns, but a spoke in site A no longer builds a direct tunnel to a spoke in site B; traffic now goes through hub-b and latency rises from 18 ms to 95 ms. show ip nhrp shortcut on the site-A spoke still lists the site-B prefix with the old hub-a next hop. Separately, a file transfer stalls whenever the packet size exceeds 1400 bytes.

1. What is the most likely reason the direct spoke-to-spoke path did not re-form after hub-a failed, and what would you verify or change?

Read the worked answer

The Phase 3 shortcut is driven by an NHRP redirect from the hub, not by the summary route alone. After hub-a fails, the site-A spoke still has a stale shortcut/NHRP entry that points at hub-a's old NBMA address. That stale entry can prevent the spoke from sending a fresh NHRP resolution for the site-B prefix, so the spoke keeps using the summary path through hub-b. The traffic works but never triggers a new redirect-based shortcut.

Verify:

show ip nhrp and show ip nhrp shortcut on both spokes; look for the destination prefix and next-hop NBMA.
show ip nhrp nhs to confirm the spoke is registered to hub-b and that hub-b is reachable.
On hub-b, confirm ip nhrp redirect is present on the mGRE interface and that ip nhrp network-id 100 matches.
Confirm the spoke has ip nhrp shortcut on the tunnel interface, not only on a physical interface.

Fix: clear the stale cache with clear ip nhrp (or wait for the 600-second holdtime to expire, which is too slow for this latency requirement). Then reduce NHRP holdtime so stale entries age faster, and test with a ping from site A to site B while watching show ip nhrp shortcut. If the shortcut still does not appear, packet-trace the first packet through hub-b to confirm hub-b is sending the redirect and that the redirect is not blocked by an ACL.

2. Why do transfers stall above 1400 bytes, and how would you correct it without breaking the underlay?

Read the worked answer

The mGRE tunnel plus IPsec encapsulation consumes more than the 1400-byte payload the application is trying to send. A typical DMVPN-over-IPsec stack adds outer IP, GRE, ESP, and possibly NAT-T headers, often 60–80 bytes. If the tunnel interface MTU is left at 1400 but TCP peers negotiate a larger MSS, the sender emits a packet that must be fragmented or that has the DF bit set. Because the provider filters ICMP, PMTUD fails silently: the large packet is dropped and the transfer stalls while small packets such as pings still work.

Correct it by making the tunnel MTU match the real encapsulation and by clamping TCP MSS:

Set ip mtu 1400 (or lower, based on the actual underlay MTU minus encapsulation) on the mGRE tunnel.
Set ip tcp adjust-mss 1360 on the tunnel interface so TCP endpoints negotiate a segment that fits inside the tunnel.
Test with ping <peer> size 1400 df-bit and increase/decrease to find the real path MTU.
Do not change the physical interface MTU; the underlay must remain at its provider-supported size.
If UDP-based applications also fail, consider whether the application has its own MTU discovery and whether it honors ICMP. TCP MSS clamping does not fix UDP.