A township public works engineer secures DMVPN with IPsec but tunnels stay down. What selector requirement must the crypto profile allow between peers?
Select an answer to reveal the explanation.
Short Explanation
IPsec has to be willing to protect GRE between those peers—if the crypto ACL or profile never matches GRE, the DMVPN wrapper never gets a secure ride.
Full Explanation
When a township public works engineer protects DMVPN with IPsec but tunnels stay down, the crypto profile or ACL must treat GRE between the peer underlay endpoints as interesting traffic. Classic crypto maps match protocol 47 (GRE) hub-to-spoke; modern profiles/VTIs must still allow the same GRE/IPsec policy so ESP can wrap the mGRE overlay. Without that selector match, IKE may come up incompletely or protected GRE never rides the SA, leaving NHRP and overlay routing dark even though underlay IP looks fine.
Restricting selectors to only TCP 179 between underlay addresses assumes DMVPN rides BGP alone and ignores that GRE encapsulation is the overlay carrier needing protection. Allowing only ICMP echo between spokes neither replaces GRE nor builds a usable civic overlay. Matching only SNMP traps from the hub does not establish NHRP mappings or encrypt GRE; traps are management noise, not tunnel selectors.
Exam caveat: distinguish underlay routing/BGP from the GRE traffic IPsec must protect; wrong ACLs are a classic “IKE up / tunnel useless” pattern. Operational check: review crypto ACL or protect statements for GRE between peer NBMA addresses, confirm SAs with show crypto session / show crypto ipsec sa showing encaps/decaps incrementing, then verify show dmvpn after crypto matches. Adjust selectors before redesigning NHRP.