A city traffic-operations center wants IPsec to encrypt traffic on its DMVPN mGRE interfaces without a separate crypto map per spoke peer. Which binding approach is the usual DMVPN pattern?
Select an answer to reveal the explanation.
Short Explanation
Tunnel protection ipsec profile is the seatbelt bolted to the mGRE tunnel. Clip it on once and it covers dynamic peers. That beats taping a new classic crypto map for every spoke public IP.
Full Explanation
A city traffic-operations center that wants IPsec on DMVPN mGRE interfaces without a separate classic crypto map per spoke peer should apply tunnel protection ipsec profile on the mGRE tunnel interfaces. The IPsec profile then protects GRE traffic to dynamic peers as NHRP brings them up, which matches DMVPN’s dynamic neighbor model. One protection binding on the tunnel scales with spoke churn instead of rewriting crypto maps for each new public IP.
Configuring only classic crypto maps matching each spoke’s public IP and leaving mGRE unprotected reverts to static peer lists and can leave the multipoint overlay unencrypted when peers change. Enabling MACsec on the ISP handoff and omitting IPsec on the tunnel protects only a local Ethernet segment, not end-to-end Internet underlay paths between townships. Using VRF-Lite route leaking instead of any IPsec profile addresses table separation, not encryption of DMVPN overlay packets.
Exam caveat: tunnel protection still needs a correctly defined IPsec profile (IKE proposal, transform set, PSK/certs); applying the command with a broken profile yields “configured but down.” Operational check: verify the profile is attached to hub and spoke mGRE interfaces, confirm dynamic IPsec sessions form as spokes register, and avoid per-spoke crypto map entries as the primary protection method for DMVPN.