A retail chain uses 80 spoke stores with dual transports behind a regional hub. Full-mesh tunnels overload small routers, but occasional store-to-store voice needs direct paths. The design requires tunnels to appear only when spoke-to-spoke traffic arrives. Which on-demand tunnel behavior should the engineer configure to meet direct spoke communication?
Select an answer to reveal the explanation.
Short Explanation
You save your small routers a ton of work with this trick. On-demand keeps the mesh dormant until real traffic wakes it, and TLOC-exchange via the Controller makes that direct path possible.
Full Explanation
The correct behavior is right because it preserves dual-transport hub connectivity for control and normal traffic while allowing two spokes to establish a direct IPsec tunnel only after actual spoke-to-spoke user packets demand it, with the Controller supplying the peer TLOC information needed to set up the shortcut, which avoids pre-provisioning 80-site state on small routers yet still provides low-latency direct voice when needed. The persistent pairwise tunnel approach fails on scalability because maintaining always-on IPsec state, BFD sessions, and per-peer tunnel state for every store pair continuously consumes memory and CPU and violates the explicit requirement that tunnels appear only on traffic arrival to prevent overload. The hub-hairpin with application-aware selection fails on topology because even well-optimized dual-transport path selection still trombones voice media through the regional hub, increasing delay, jitter, and hub load instead of providing the mandated direct spoke-to-spoke media path. The routing-update-triggered shortcut approach fails on trigger semantics because creating direct IPsec from control-plane reachability proactively builds tunnels before user traffic flows, which contradicts the data-plane-triggered on-demand condition. The exam caveat is to parse trigger wording carefully and distinguish control-plane reachability from data-plane demand, since many dynamic tunnel designs sound similar but differ critically on when establishment occurs. The practical check is to leave spokes idle then generate inter-store voice and confirm from the spoke BFD sessions and tunnel tables that no direct tunnel exists at idle and a direct IPsec tunnel forms immediately after the first media packets arrive.