A municipal hospital must multi-tenant guest Wi-Fi routing away from clinical systems on shared edge routers. What is the primary VRF benefit in that design?
Select an answer to reveal the explanation.
Short Explanation
Hospital guest Wi-Fi and clinical gear can share the metal routers but not the same route book. VRFs give each tenant its own table so a mistaken guest path does not stroll into clinical prefixes unless you deliberately open a door.
Full Explanation
A municipal hospital that must multi-tenant guest Wi-Fi routing away from clinical systems on shared edge routers gets its primary VRF benefit from separate routing tables. VRFs keep guest and clinical prefixes isolated on the same physical routers unless explicit leaking is configured, so shared hardware does not imply a shared RIB. That isolation is the core multi-tenant routing benefit for hospital edge designs that cannot afford guest paths into clinical networks. VRFs do not merge guest and clinical tables into one RIB to simplify traceroute—that reverses the isolation goal. VRFs do not replace wireless controllers so SSIDs no longer need authentication; WLAN authentication architecture remains a separate concern from routing-table virtualization. VRFs also do not convert all guest traffic into VXLAN automatically without VTEPs; VXLAN requires overlay components and is not an automatic side effect of enabling VRF. Exam caveat: default isolation holds until import/export, static leaks, or shared-global mistakes reintroduce connectivity—VRF is necessary but not sufficient if policy later punches holes. Operational check: assign guest and clinical interfaces to distinct VRFs on the hospital edge, confirm separate show ip route vrf outputs, attempt guest-sourced reachability to clinical prefixes (should fail without leak), and document any intentional shared services with audited leak scope.