A water utility must keep SCADA routing separate from guest Wi-Fi on the same edge router. Which data-path virtualization approach best meets that need?
Select an answer to reveal the explanation.
Short Explanation
VRFs are like giving the SCADA trucks and the coffee-shop guests different map books in the same glove compartment. Same router chassis, different route tables—so a wrong turn in guest Wi-Fi does not dump you into the plant control network.
Full Explanation
A water utility that must keep SCADA routing separate from guest Wi-Fi on the same edge router needs data-path virtualization that isolates routing tables, not just addresses on the wire. VRF-lite (VRF without requiring MPLS in many enterprise designs) maintains multiple independent routing tables on one device so SCADA and guest prefixes do not share a global RIB by default. That table separation is exactly what prevents a wrong turn in guest Wi-Fi from injecting paths into plant control routing on the shared civic edge router. Collapsing both domains into one global routing table and relying on NAT alone fails by concept: NAT translates addresses but does not create separate RIBs or stop control-plane contamination between SCADA and guest. Disabling CEF so each interface maintains its own CAM table conflates Layer 2 forwarding caches with routing-table isolation and harms performance without delivering VRF semantics. Replacing edge routing with a single stretched Layer 2 VLAN across SCADA and guest worsens blast radius and abandons Layer 3 separation the utility needs. Exam caveat: VRF-lite isolates tables until someone configures import/export or leaking; isolation is default behavior, not a guarantee against later misconfiguration. Operational check: place SCADA and guest interfaces or subinterfaces in distinct VRFs on the water-utility edge router, confirm each VRF shows only its intended prefixes with show ip route vrf, and verify that guest traceroute or pings cannot resolve SCADA destinations without an explicit, audited leak.