Campus Trunk, DHCP Relay, and Access-Layer Loop
A three-floor office has 120 users and 60 VoIP phones per floor. Each floor has one 48-port access switch; the switches connect to a collapsed core over a single 1 Gbps fiber uplink. VLAN 10 is for users, VLAN 20 for phones, and VLAN 30 for access points. The native VLAN is 1 on every trunk, and spanning tree is left at defaults. The DHCP server sits in the data center; the core has switched virtual interfaces for all three VLANs, but ip helper-address is configured only on VLAN 10. After a user connected a spare unmanaged switch between two wall ports on floor 2, the whole campus became slow. Separately, phones on floor 3 sometimes receive VLAN 10 addresses. The core uplink is at 70-80% utilization during peak, and broadcast traffic is high. The company cannot add new fiber this quarter.
1. Why do floor 3 phones sometimes get VLAN 10 addresses, and what configuration change fixes it without moving the DHCP server?
Read the worked answer
The phones are probably landing in VLAN 10 at the access port, not merely failing DHCP relay. If the port is configured as an access port in VLAN 10 and the phone is not being told to use voice VLAN 20 via LLDP-MED or vendor discovery, the phone untagged DHCP request stays in VLAN 10 and gets a VLAN 10 lease. The missing ip helper-address on VLAN 20 would cause a phone actually in VLAN 20 to fail DHCP entirely and likely fall back to 169.254, not a VLAN 10 address.
Fix both: configure the access ports with data VLAN 10 and voice VLAN 20, enable the phone discovery protocol, and add helper addresses for VLAN 20 and VLAN 30 on the core SVIs. Keep the DHCP server in the data center; the relay is the core SVI, not the access switch. Verify with the phone IP address, its VLAN, and a capture showing the DHCPDISCOVER reaching the server with the correct giaddr.
2. What infrastructure changes prevent the unmanaged-switch loop from taking down the whole campus, and what are the tradeoffs?
Read the worked answer
The loop is an access-layer problem, so protections belong at the access edge. Enable RSTP or MST consistently, set a deliberate root bridge on the core, and use Root Guard on core-facing ports. On user ports, enable PortFast and BPDU Guard, but note that an unmanaged switch may not send BPDUs, so BPDU Guard alone may not catch it. Add storm control for broadcast, multicast, and unknown unicast; use port security with a MAC limit; and disable unused ports. Use a dedicated unused native VLAN instead of VLAN 1, and prune unnecessary VLANs from trunks. Monitor MAC flapping and interface CPU to catch the next loop.
The tradeoff is operational: storm control can drop legitimate broadcast traffic, port security can lock out a user who changes devices, and BPDU Guard will err-disable a port when a rogue managed switch is attached. Those are acceptable if the help desk has a documented recovery process.
3. Is one 1 Gbps uplink adequate for each floor? Show the reasoning and immediate alternatives given no new fiber this quarter.
Read the worked answer
One 1 Gbps uplink is marginal for 180 endpoints and is already near peak. A rough edge capacity is 120 users at 1 Gbps plus 60 phones at 100 Mbps plus APs, which is far above 1 Gbps if all ports are active; the uplink is therefore heavily oversubscribed. Real traffic is bursty, so 70-80% peak utilization is a warning sign, not proof of failure. Broadcast traffic from the loop and from a flat VLAN 1 native design makes it worse.
Since new fiber is not available this quarter, immediate steps are storm control, VLAN pruning, DHCP relay on all VLANs, and moving the native VLAN off VLAN 1. When fiber is available, add a 10 Gbps uplink or a 2x1G LAG if the existing fiber pair and switch support it. Do not treat the uplink as the only cause; the loop must be fixed first.