A county elections office finds that DMVPN spokes can reach the hub but never form direct spoke-to-spoke paths, so inter-branch traffic keeps hairpinning. Which cause fits that symptom at ENARSI depth?
Select an answer to reveal the explanation.
Short Explanation
When you see hub reachability but no direct spoke-to-spoke paths, look first at NHRP: missing or failing shortcut/redirect behavior keeps spokes from resolving each other’s NBMA addresses. Check resolution before you redesign the WAN.
Full Explanation
When spokes can reach the hub but inter-branch traffic keeps hairpinning, missing or failing NHRP shortcut/redirect behavior fits the symptom: spokes never resolve each other’s NBMA addresses and cannot build the shortcut tunnel. Hub-spoke DMVPN can still look healthy, with registration and overlay IGP reachability to the hub, while spoke-to-spoke optimization is broken. A hub without a public IP while every spoke uses a static NBMA address does not fit the working hub-spoke symptom; without a reachable hub NHS, spokes typically could not reach the hub either. The claim that hub mGRE always blocks spoke-to-spoke paths is false: mGRE enables multipoint DMVPN, while shortcuts depend on NHRP and the DMVPN phase. Working IPsec does not inherently prevent NHRP registration; protected DMVPN registers over the encrypted overlay/control path as designed. Exam caveat: distinguish Phase 1, which is hub-spoke only by design, from a Phase 2 or Phase 3 design where shortcuts are expected but redirect/resolution is broken. Practical check: verify NHRP redirect/shortcut configuration on hub and spokes, trigger inter-branch traffic, watch for NHRP resolution messages, and confirm dynamic spoke-to-spoke mappings appear. If they do not, fix NHRP before redesigning WAN routing.