DMVPN Phase 2 Spokes Never Build Direct Tunnels
A managed service provider runs a hub-and-spoke WAN as DMVPN Phase 2. The hub has one mGRE Tunnel0 (172.16.1.1/24), 60 spokes register through NHRP with tunnel addresses 172.16.1.11 to 172.16.1.70, EIGRP AS 100 runs inside the tunnel, and every router protects the tunnel with tunnel protection ipsec profile DMVPN in transport mode. Spoke LANs are 10.1.X.0/24.
The hub carries no ip split-horizon eigrp 100 but also still has ip next-hop-self eigrp 100 on Tunnel0, left over from the original Phase 1 build. The design document requires direct spoke-to-spoke tunnels. In practice every inter-branch flow transits the hub: RTT between two branches is 40 ms while the direct Internet path between the same sites measures 9 ms, and the hub's 100 Mbps uplink is saturated at peak. show ip nhrp on the spokes lists exactly one peer. Tunnel MTU is 1400 everywhere, but users report that SSH sessions to remote branches hang once output exceeds a few kilobytes, while ping works.
1. Explain why no spoke-to-spoke tunnels are formed in this design, and state exactly what must change on the hub.
Read the worked answer
In Phase 2 the hub must advertise spoke prefixes with the original next hop intact. If a spoke's route to 10.1.20.0/24 has next hop 172.16.1.20 (the remote spoke's tunnel address), that next hop is not on-link for the multipoint tunnel, so the spoke triggers an NHRP resolution for 172.16.1.20, learns the remote NBMA address, and builds a direct IPsec/GRE tunnel to it. The hub is then used only for the initial resolution and for traffic to unknown destinations.
With ip next-hop-self eigrp 100 the hub rewrites the next hop to 172.16.1.1. The spoke's route now points at the hub, which is already resolved and reachable, so NHRP is never triggered and no shortcut is ever built. Phase 2 has no redirect mechanism; the ip nhrp redirect and ip nhrp shortcut pair that corrects this is a Phase 3 feature, and it is not configured here. Spokes therefore forward everything to the hub.
Fix: remove ip next-hop-self eigrp 100 from Tunnel0 on the hub, keep no ip split-horizon eigrp 100 so the hub still advertises spoke routes back out the tunnel, and confirm that spokes do not have their own next-hop-self settings. After the change, check show ip route 10.1.20.0 on a spoke for a next hop of 172.16.1.20 via Tunnel0.
2. Users report that SSH sessions to remote branches hang after a few kilobytes of output while ping is fine. Diagnose the cause and specify the fix across all 61 routers.
Read the worked answer
Ping works because the payload is small; the failure appears only when a TCP segment must be carried whole. A host on a 1500-byte LAN sends a 1500-byte segment with DF set. GRE and IPsec transport mode add roughly 60 to 100 bytes, so the packet exceeds the 1400-byte tunnel MTU. The router cannot fragment a DF packet and should return ICMP fragmentation-needed, but that ICMP is frequently dropped inside the tunnel or by intermediate firewalls, so path MTU discovery silently fails and the sender retransmits the same oversized segment forever. The TCP handshake and short commands succeed, which is why the session looks alive.
Fix it at the MSS layer rather than by raising the MTU. On every tunnel interface, hub and all 60 spokes, configure ip mtu 1400 and ip tcp adjust-mss 1360 (1400 minus 40 bytes of IP and TCP headers). adjust-mss rewrites the MSS option in the SYN and SYN-ACK that cross the tunnel, so both endpoints limit themselves to segments that fit, and no fragmentation is needed.
Note the limitations: it only helps TCP, it only works if the tunnel is in the path of the handshake, and UDP-based protocols still rely on PMTUD. If ICMP cannot be trusted on the underlay, also consider clearing the DF bit on encapsulated packets so the tunnel can fragment as a fallback.
3. After the shortcut problem is corrected, how do you prove that spoke-to-spoke forwarding actually works, and what operational caveats should you document?
Read the worked answer
Start on a spoke after generating traffic. show ip nhrp should now list a dynamic entry for the remote spoke tunnel address with its NBMA address, in addition to the hub. show ip route 10.1.20.0 should show next hop 172.16.1.20 out Tunnel0, not the hub. show crypto session or show crypto ikev2 sa on both spokes should show a peer-to-peer SA whose remote address is the other spoke's public address, not the hub. show dmvpn on the hub confirms the NHRP entries and their state, and a traceroute between branches should show two hops rather than three.
Document the caveats. The first packet of a new flow still goes to the hub while NHRP resolution completes, so there is a short delay and possibly a couple of retransmissions; keep this in mind for short-lived request-response applications. Spoke-to-spoke tunnels consume IPsec SAs on every spoke proportional to the peers it talks to, which matters at 60 spokes. Spoke NAT devices break the NBMA reachability and must be avoided or handled explicitly. Finally, the hub's crypto and NHRP configuration must permit any-to-any, and the underlay ACLs between spoke public addresses must allow ESP and UDP 500/4500 both ways.