A hospital group must keep clinical, guest, and research traffic isolated across two campuses with common switches and a shared WAN, while allowing controlled guest Internet breakout only. Which VRF segmentation design best meets this multi-campus isolation requirement?
Select an answer to reveal the explanation.
Short Explanation
You've got three busy hallways that shouldn't mix, so you'll give each domain its own VRF end-to-end and use route leaking only for guest internet exit. That way your clinical and research traffic stay completely sealed off.
Full Explanation
The correct design maintains separate routing instances for clinical, guest, and research from access through campus VRF-Lite or 802.1Q-mapped VRFs into distinct MP-BGP VPNv4 and VPNv6 instances across the shared MPLS or SD-WAN backbone, preserving path and policy separation on common hardware while a single controlled route-leak or extranet NAT point permits guest default toward the Internet firewall without importing Internet or inter-domain routes elsewhere. Deploying equivalent leaking for clinical and research Internet access is operationally common for direct Internet access designs but violates the controlled-only-guest constraint and expands attack surface by exposing regulated clinical systems and research networks to external reachability and policy bypass. Keeping strong local separation yet merging everything into one VPN over the WAN is standard for cost and operational simplification but defeats multi-campus segmentation because a single RD and RT domain reintroduces mutual reachability in transit and prevents per-domain policy enforcement across sites. Using per-campus rather than per-domain VRFs with local breakout is typical for geographic isolation but fails the domain requirement because co-locating clinical, guest, and research in the same table on shared switches allows lateral movement via switched adjacencies despite physical site separation. For exams, distinguish scope of isolation from scope of leaking, as wording such as only, end-to-end, or shared often signals the discriminator between otherwise valid architectures. In practice, verify with show vrf detail, show bgp vpnv4 unicast and route-target import-export maps, plus VRF-aware traceroute to confirm separation and that only the guest table learns the breakout default.