A city clerk's office streams site-to-site video between two DMVPN spokes and wants to avoid hairpinning through HQ. What benefit does a direct spoke-to-spoke IPsec path provide?
Select an answer to reveal the explanation.
Short Explanation
Once spokes learn each other's public address, they talk encrypted straight across—video does not have to take the scenic route through city hall.
Full Explanation
When a city clerk’s office streams site-to-site video between two DMVPN spokes, a direct spoke-to-spoke IPsec path after NHRP resolution avoids hairpinning through HQ. Spokes learn each other’s NBMA addresses, build a dynamic tunnel, and encrypt video directly—cutting latency and offloading hub CPU and bandwidth that would otherwise replicate every frame through city hall during peak recording or council-feed transfers.
Forcing all video through the hub so HQ can apply NetFlow on every frame is the hairpin anti-goal, not the spoke-to-spoke benefit; NetFlow can still be designed at spokes or selective aggregation points. Disabling encryption so GRE alone carries citizen video trades security for latency and is not the intended benefit on a public underlay. Replacing NHRP with static host routes redistributed into OSPF on every spoke abandons dynamic discovery and recreates mesh routing toil across clerk sites.
Exam caveat: spoke-to-spoke value is latency and load reduction with security retained via IPsec after NHRP. Operational check: enable redirect and shortcut, start a clerk video flow, confirm direct spoke mappings and IPsec SAs, and compare hub throughput before and after to show hairpin avoidance.