A municipal fiber consortium sees a spoke that cannot pass overlay traffic. Before blaming NHRP mappings, what protected-DMVPN prerequisite should the engineer confirm?
Select an answer to reveal the explanation.
Short Explanation
If the crypto SA isn’t even up, stop yelling at NHRP. Encrypted DMVPN needs IPsec standing before mapping mysteries matter.
Full Explanation
When a municipal fiber consortium sees a spoke that cannot pass overlay traffic, a protected-DMVPN prerequisite to confirm before deep NHRP mapping hunts is that IPsec security associations for the tunnel protection profile are up between the spoke and hub. If Phase 1/2 (IKE/IPsec) SAs are down, GRE/NHRP and overlay routing cannot reliably operate on an encrypted design. Establishing crypto health first prevents misattributing a tunnel-protection failure to NHRP or IGP symptoms.
Checking MP-BGP VPNv4 sessions to every P router targets MPLS L3VPN, not Internet DMVPN. Preferring that the spoke has disabled tunnel protection so GRE runs cleartext only is the wrong security posture for a protected design and does not validate the required prerequisite. Looking for LDP label bindings for the spoke’s LAN VRF on the ISP core again mixes provider MPLS L3VPN troubleshooting into a DMVPN problem.
Exam caveat: after SAs are up, still verify NHRP registration and overlay routing—crypto up is necessary but not sufficient. Operational check: on spoke and hub inspect IPsec SA status for the tunnel profile (show crypto session / show crypto ipsec sa), confirm tunnel protection is applied to the mGRE interface, then re-check show dmvpn and overlay pings; only escalate to NHRP mapping analysis once SAs are established.