A public-library branch renumbers its ISP public address. Afterward, DMVPN peers still show an old NBMA mapping for that spoke and tunnels misbehave. What NHRP troubleshooting focus fits?
Select an answer to reveal the explanation.
Short Explanation
An old public IP still sticky in NHRP is like a contacts app keeping a roommate’s ancient cell number. Clear or refresh the stale mapping so peers learn the spoke’s new NBMA address. Then let the spoke re-register cleanly.
Full Explanation
After a public-library branch renumbers its ISP public address, peers that still show the old NBMA mapping will mis-encapsulate toward a stale underlay endpoint. The fitting NHRP troubleshooting focus is to clear or refresh stale NHRP mappings so the hub and any shortcut peers learn the spoke’s new NBMA address, then allow the spoke to re-register. Stale NBMA entries are a classic post-renumbering failure mode even when overlay IPs and IGP configuration are unchanged.
Ignoring NHRP and only clearing OSPF on underlay ISP routers does not update tunnel-to-NBMA bindings the DMVPN overlay depends on. Changing a route distinguisher on a non-existent PE VRF invents an MPLS L3VPN action irrelevant to library DMVPN. Disabling mGRE on the hub permanently so only point-to-point GRE remains is a destructive redesign, not a targeted fix for stale mappings after renumbering.
Exam caveat: also verify DNS/static references to the old public IP in spoke NHS configs if the hub moved; this stem is spoke renumbering, so focus on spoke NBMA refresh and re-registration. Operational check: clear NHRP entries on hub/peers (clear ip nhrp as appropriate), bounce or re-register the spoke, confirm show ip nhrp / show dmvpn displays the new public address, and retest overlay traffic before chasing unrelated control-plane resets.