Layer 2/Layer 3 Boundary for a New Distribution Center
A 480-employee distribution center is moving into a refurbished three-floor building. Each floor will hold 150 desk users, 40 IP phones and 14 Wi-Fi 6 access points; the warehouse adds 200 handheld scanners and 60 IP cameras. The inherited design gives each floor one /24 VLAN, with all default gateways on a pair of aging core switches and 1 Gbps uplinks to 2960X access stacks. The fiber riser can provide two 10 Gbps pairs to each floor. Two constraints have surfaced. The warehouse inventory application relies on broadcast-based discovery and the vendor will not support it across subnets. Security also requires camera traffic to be fully separated from user and voice traffic. The company owns 10.20.0.0/16, but 10.20.5.0/24 through 10.20.9.0/24 are already used by a neighboring plant reachable over a 1 Gbps Metro Ethernet link that runs OSPF with the distribution center.
1. Where should the Layer 2/Layer 3 boundary sit, and what addressing plan would you propose? Give concrete subnet sizes and justify them against the two constraints.
Read the worked answer
Boundary. The 2960X stacks are Layer 2 only, so the boundary must be the distribution switches that terminate each floor's fiber pair. Access stays Layer 2 with 802.1Q trunks and EtherChannel; each floor gets a VRRP gateway pair on the distribution switches. The core stays a routed OSPF area 0. This contains STP to one closet pair and avoids a building-wide broadcast domain.
Addressing. 150 desks per floor fits a /24 with roughly 40% growth headroom, which is a better trade-off than /25s that strand addresses at the first VLAN change:
- Users: 10.20.16.0/24, 10.20.17.0/24, 10.20.18.0/24
- Voice: 10.20.19.0/25 and 10.20.19.128/25, DHCP option 150 from the call manager
- AP management: 10.20.20.0/27, .32/27, .64/27
- Scanners: 10.20.24.0/28 per scanner zone, pinned to the stack serving that zone
- Cameras: 10.20.26.0/25 per zone with an ACL permitting only the NVR
- Uplinks: /31s out of 10.20.255.0/24
Keep clear of 10.20.5.0–10.20.9.0/24 and advertise a single 10.20.16.0/20 summary toward the Metro neighbor.
Why not one VLAN. A single /24 across three floors makes every broadcast and STP change a building-wide event and would stretch the scanner broadcast domain over the 1 Gbps Metro link, where a storm could break the OSPF adjacency with the plant. The scanner exception stays local.
2. How do you keep the broadcast-dependent inventory application working without stretching a VLAN across the building or over the Metro link?
Read the worked answer
The vendor constraint is real but narrow: it requires a shared broadcast domain, not a building-wide one. Scope it to the smallest topology that satisfies discovery - the stack pair and access switches serving one scanner zone - and never trunk that VLAN to the core or the Metro link.
Mitigations, in order of preference:
- Ask the vendor for directed or unicast discovery; many clients support a discovery server address, which removes the requirement entirely.
- If discovery is multicast rather than broadcast, enable IGMP snooping and an IGMP querier on the scanner VLAN so traffic is not flooded to every port.
- Measure the baseline broadcast rate first (typically well under 100 pps at this scale), then set storm control at roughly 10x baseline, not at a default percentage that will trip during imaging.
- Put a local inventory relay or discovery proxy in each zone if the handhelds roam between floors, so roaming does not force a stretched VLAN.
- Apply an ACL so the scanner VLAN can reach only the inventory servers, limiting the blast radius of a rogue device.
The judgement point: a broadcast dependency justifies a small, contained Layer 2 island, not a return to flat Layer 2 design.
3. What failure domains remain in your design, and what would you test before cutover to prove they are controlled?
Read the worked answer
Remaining failure domains.
- The distribution pair becomes the transit point for every floor. Dual supervisors and dual uplinks to the core are mandatory; a single distribution chassis is a building outage.
- VRRP plus spanning tree can interact badly: dual-homed access links without EtherChannel create an L2 loop, and a VRRP failover that takes 3 seconds still drops every voice call on that floor.
- The OSPF adjacency to the plant rides a Metro Ethernet link that is effectively one broadcast segment. A summary with no matching component route, or a flapping adjacency, will blackhole plant-bound traffic silently.
- Broadcast suppression configured too aggressively will look exactly like an application fault.
Pre-cutover tests.
- Pull one fiber in the distribution pair and measure VRRP and OSPF convergence; target sub-second for VRRP with BFD or fast hellos.
- Measure broadcast and multicast rates per VLAN at idle, during imaging and during a scanner discovery storm.
- Verify the 10.20.16.0/20 summary by withdrawing a component route and confirming traffic still follows the intended path.
- Check STP root placement so the root is the distribution pair, not an access stack.
- Confirm voice survives a gateway failover with a test call during the change window.