A building-permits office wants two branch spokes to exchange traffic directly after the first packets hairpin via HQ. Which NHRP behavior enables those dynamic spoke-to-spoke NBMA mappings?
Select an answer to reveal the explanation.
Short Explanation
First packets may swing by HQ, then NHRP redirect and resolution hand out the other spoke’s public address. After that, the spokes can build a shortcut and stop hairpinning. That’s the dynamic spoke-to-spoke mapping story.
Full Explanation
A building-permits office that wants two branch spokes to exchange traffic directly after an initial hairpin through HQ relies on NHRP redirect and resolution. The hub informs spokes that a better NBMA path exists; spokes resolve each other’s public addresses and build a shortcut tunnel so subsequent packets bypass the hub. That dynamic spoke-to-spoke mapping is the control-plane behavior behind Phase 2/3 shortcut efficiency in civic DMVPN WANs.
Provisioning static NHRP map entries on every spoke for every other spoke before first use reintroduces the O(N²) static problem DMVPN is meant to avoid. Disabling NHRP on the hub so spokes flood NBMA info with OSPF alone removes the NBMA resolution service; OSPF can share overlay prefixes but does not replace NHRP’s tunnel-to-NBMA mappings. MP-BGP route-target import between spoke CE routers is an MPLS L3VPN concept, not the DMVPN spoke-to-spoke shortcut mechanism.
Exam caveat: hairpinning on first packets can be normal until resolution completes; persistent hairpinning implies redirect/shortcut failure, not necessarily total DMVPN failure. Operational check: generate spoke-to-spoke traffic, then verify dynamic peer/mapping entries to the remote spoke’s NBMA in show dmvpn / show ip nhrp, and confirm CEF/tunnel adjacency no longer forces all inter-branch packets solely via the hub.