A 911 PSAP needs predictable underlay transport plus overlay encryption. How should architects separate responsibilities in Cisco SD-WAN principles?
Select an answer to reveal the explanation.
Short Explanation
Underlay is the roads; overlay is the armored car service running on those roads. PSAP needs solid roads and locked cars—don’t swap the labels.
Full Explanation
A 911 PSAP that needs predictable underlay transport plus overlay encryption should separate responsibilities so the underlay supplies IP reachability/transport while the overlay provides SD-WAN segmented, typically encrypted site-to-site forwarding on top. Predictable circuits, routing, and SLA live in the underlay; segmentation and IPsec (or equivalent overlay protection) live in the overlay. Mixing those labels breaks both design and troubleshooting for emergency communications.
Saying the overlay provides raw dark fiber only while the underlay encrypts SIP using Spanning Tree reverses roles and invents STP-as-encryption nonsense. Claiming the underlay terminates CAPWAP from APs while the overlay runs only inside each access VLAN bridge confuses campus wireless with SD-WAN site overlay. Requiring both underlay and overlay to be identical VRFs that never encapsulate traffic denies the encapsulation model SD-WAN uses.
Exam caveat: Underlay = transport reachability; overlay = segmented/encrypted SD-WAN forwarding—keep them straight for PSAP-grade designs.
Operational check: document underlay SLAs and routing for the PSAP, confirm overlay tunnels encrypt site traffic, and run failure tests that distinguish underlay brownouts from overlay/IPsec failures.