A wastewater treatment plant places SCADA and office interfaces into different VRFs on one IOS XE router. What must operators remember when finishing that VRF-Lite build?
Select an answer to reveal the explanation.
Short Explanation
Each VRF is its own mini-router brain. Interfaces must join the right cabinet, and you still configure IPs and routing inside that context—nothing magically spills over from global.
Full Explanation
Finishing VRF-Lite at the wastewater plant means treating each VRF as an independent router context: create the VRF, assign interfaces with ip vrf forwarding (reapply IP addresses after assignment on classic IOS), and configure addressing plus routing protocols or statics inside each VRF so SCADA and office tables populate independently.
It is false that only the global table needs OSPF and VRF interfaces inherit routes automatically from CEF—CEF forwarding entries follow the VRF RIB; routes are not inherited from global by magic. Assigning both VRFs the same MPLS L3VPN-style route distinguisher is unnecessary for VRF-Lite isolation and misunderstands Lite versus full MPLS VPN requirements. Disabling IP routing globally so VRF tables learn exclusively via proxy ARP breaks Layer-3 routing entirely and is not a VRF-Lite build step.
Exam caveat: after ip vrf forwarding, interfaces lose their IP until reconfigured—a common operational surprise. Named VRF definitions on IOS XE and per-VRF address-families for BGP/EIGRP/OSPF are the modern pattern.
Operational check: show vrf, show ip interface brief (VRF column), show ip route vrf <scada|office>, and protocol adjacency shows scoped to each VRF. Ping/CEF lookups must specify VRF to avoid false negatives during validation.