A township board’s DMVPN spokes still hair-pin all spoke-to-spoke traffic through the hub. Which missing Phase 3 features are the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
Still hair-pinning? The hub never waved the "go talk directly" flag — that flag is NHRP redirect, and spokes need shortcut enabled to listen. Fix those two and township spokes can build the direct path. mGRE stays; do not blame IKE version first.
Full Explanation
Persistent hub hair-pinning on a township board design that intends Phase 3 usually means NHRP redirect is missing on the hub or shortcut is missing on spokes, so dynamic spoke-to-spoke tunnels never form. Those two features are the most direct cause to verify before redesigning routing or crypto.
Identical EIGRP AS numbers with split horizon left enabled at the hub affect routing advertisement, not the NHRP redirect mechanism itself. Replacing mGRE with point-to-point GRE abandons the DMVPN multipoint model. Mandating IKEv1 only because IKEv2 cannot protect redirected spoke tunnels is false—IKEv2 is fully capable.
Exam caveat: hair-pinning with Phase 3 intent → check redirect/shortcut first; do not leap to IKE version or point-to-point GRE.
Operational check: verify NHRP redirect on the hub and shortcut on spokes, clear NHRP as needed, retest township spoke-to-spoke flows, and confirm direct tunnels appear in NHRP and crypto session tables. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.