A city clerk’s office runs DMVPN over Internet transports and must encrypt mGRE overlay traffic. What mechanism binds that encryption to the tunnels?
Select an answer to reveal the explanation.
Short Explanation
mGRE over the Internet without IPsec is a postcard; with an IPsec profile it becomes a sealed envelope. Tunnel protection binds the crypto to the DMVPN tunnel interface. EXP tricks and PHP do not encrypt the overlay for the city clerk.
Full Explanation
DMVPN overlays on public Internet should use IPsec tunnel protection: an IPsec profile bound to the mGRE tunnel encrypts and authenticates overlay packets for a city clerk’s office. Profile-based tunnel protection is the standard way to apply modern IKE/IPsec to DMVPN without per-peer crypto maps for every spoke.
Exporting MPLS EXP bits into GRE keys so P routers encrypt spoke packets does not provide DMVPN IPsec. Enabling PHP on the hub so cleartext mGRE is popped before Internet egress confuses MPLS PHP with encryption. Advertising VPNv4 routes over the tunnel to “imply IPsec” without a crypto profile provides no confidentiality.
Exam caveat: tunnel protection / IPsec profile on mGRE is the binding mechanism—QoS marking and MPLS tricks are not substitutes.
Operational check: apply matching IPsec profiles on clerk hub and spokes, confirm ESP SAs, verify overlay traffic is encrypted on the Internet underlay, and align IKE versions with policy. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.