Stretched clinical VLANs vs. local departmental VLANs in a three-building campus
Northgate Health is building a three-building Fabric Connect campus: two VSP 8600 core switches, six VSP 7400 distribution switches (two per building), and 84 VSP 4900 access switches. The campus has 2,800 wired endpoints, 620 access points, and 110 clinical VLANs that must exist in all three buildings. Another 310 departmental VLANs only need local building presence. The data center already uses ISIDs 10,000–19,999 and B-VLANs 3002 and 3003, and the campus fabric must not overlap those values. The CIO wants one common gateway IP per clinical subnet across all buildings and IP multicast for 40 IPTV channels. The implementation team proposes mapping all 420 VLANs to L2 VSNs so that 'everything is the same' and operations are simpler.
1. Should all 420 VLANs be L2 VSNs? Decide which VLANs are stretched and which are routed, and justify the choice against the stated requirements.
Read the worked answer
Decision: only the 110 clinical VLANs should be L2 VSNs. The 310 departmental VLANs should terminate on IP interfaces at the building distribution switches and be advertised as IP shortcuts.
Why: an L2 VSN extends the broadcast domain and all BUM traffic to every edge node that attaches the ISID. Stretching 420 VLANs would multiply unknown-unicast and broadcast flooding across 84 access switches, enlarge MAC and ARP scaling, and widen the blast radius of a loop or misconfiguration. The 110 clinical VLANs genuinely need one subnet and one gateway IP in all three buildings, so an L2 VSN is appropriate. The departmental VLANs do not; routing them locally gives fault containment and still provides any-to-any reachability through IP shortcuts.
The ISID space is 24-bit, so ISID exhaustion is not the binding constraint. The constraints are operational scale and failure domain. For the 40 IPTV channels, route multicast at the core and enable IGMP snooping and a querier on the clinical ISIDs; do not rely on flooding. If a departmental VLAN later needs to span buildings, convert only that VLAN to an L2 VSN rather than stretching all 310.
2. Produce the ISID, B-VLAN, and nickname plan. What must be verified before the first edge switch is commissioned?
Read the worked answer
ISIDs: allocate 20,000–20,109 to the 110 clinical VLANs, with 20,110–20,199 reserved for growth. Map each clinical VLAN to one ISID and document the VLAN-to-ISID binding.
B-VLANs: if the campus fabric will remain separate from the data center, use 3004 as primary and 3005 as secondary to avoid an accidental merge conflict. If the fabrics will be interconnected, reuse 3002/3003 and treat the B-VLAN assignment as fabric-wide. In either case, the primary and secondary B-VLANs must be configured identically on every fabric node and allowed on every ISL; a missing B-VLAN on a transit link causes selective forwarding failure rather than an obvious adjacency drop.
Nicknames: assign one unique nickname per node, derived from a documented building/role/node index, never from an access-switch loopback alone. Record it in IPAM/DCIM.
Pre-commissioning checks: unique system IDs and nicknames; IS-IS level and area match; MTU consistent on all fabric ports; B-VLANs allowed on all ISLs; clinical VLAN/ISID mappings present on every edge node that needs them; IP shortcut filters reviewed; and a canary edge switch validated before the remaining 83.
3. Where should DvR controller and leaf roles be placed for the clinical subnets? What failure mode should the design account for?
Read the worked answer
Place the DvR controller on one core VSP 8600 and DvR leaf roles on the distribution switches (and on the second core if it also provides clinical gateways). DvR gives the clinical subnets a consistent anycast default-gateway IP and MAC at the leafs, which matches the requirement for one gateway IP per subnet and avoids running VRRP on 110 subnets.
The design must account for controller reachability. DvR is a control-plane role; leafs need to reach the controller through the fabric to install the virtual router state. Put the controller on a node with redundant IS-IS paths, and test a controller reload during a maintenance window. Validate in the release notes whether leafs retain forwarding while the controller is unavailable; do not assume it. If the clinical requirement is sub-second gateway redundancy with no dependence on a single controller, VRRP on the SMLT core pair is the lower-risk alternative, at the cost of per-subnet configuration. DvR also requires IP shortcuts or an L3 VSN, so confirm the clinical subnets are actually routed, not just bridged.