DHCP Snooping Trust Breaks a Campus Access Switch
At a 3,000-student campus, access switch SW-A serves 44 ports: 20 PCs in VLAN 10, 20 IP phones in VLAN 30, and 4 lobby ports. The uplink is a single 802.1Q trunk to distribution switch SW-D carrying VLANs 10, 30, and 99; SW-A's management SVI is VLAN 99. DHCP snooping was enabled campus-wide last week on all access VLANs, with the uplink to SW-D deliberately left untrusted 'for safety'. Since then roughly a third of PC users report no internet, and ipconfig shows 169.254.x.x addresses. Phones still register because they use static addressing with Option 150 pointing at a local TFTP server. SW-A logs %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on Gi1/0/1 (99), with SW-D Gi0/12 (1). Separately, an unmanaged 8-port switch was found daisy-chained in the lobby, and unused ports remain in VLAN 1.
1. Diagnose the 169.254.x.x symptom. Which DHCP snooping behavior explains it, and what exactly should be changed?
Read the worked answer
169.254.x.x is APIPA, meaning the client sent DISCOVER and never received an OFFER. DHCP snooping classifies each port as trusted or untrusted and, on untrusted ports, drops server-sourced DHCP messages (OFFER, ACK, NAK) while still allowing client messages (DISCOVER, REQUEST) to pass. Because the trunk to SW-D was left untrusted, every OFFER relayed from the DHCP server toward the PCs is discarded at SW-A's uplink, so clients time out and self-assign.
The phones are the useful control: they are statically configured, so VLAN 10 transport, trunk tagging, and STP are all demonstrably working. The fault is the trust boundary, not reachability.
Fix: apply ip dhcp snooping trust to the uplink (and to any port facing the DHCP server or relay), keep access ports untrusted, and confirm ip dhcp snooping vlan 10,30 matches the intended scope. Do not 'fix' this by disabling snooping. Verify with show ip dhcp snooping, show ip dhcp snooping binding, and a capture showing the OFFER arriving and being forwarded. Also check whether Option 82 insertion is enabled and whether the DHCP server accepts it, since a strict server may drop relayed requests.
2. A junior engineer wants to fix the native VLAN mismatch first, claiming it causes the DHCP failures. Evaluate that claim and describe the real risk of the current mismatch.
Read the worked answer
The claim is wrong. Frames for VLANs 10 and 30 are 802.1Q-tagged on the trunk, and the tag carries the VLAN ID, so a native VLAN disagreement on VLAN 1 versus 99 does not affect them. The mismatch cannot explain APIPA. Correlation in timestamps is not causation.
The real damage is elsewhere. Untagged frames on one side land in VLAN 99 and on the other in VLAN 1, so untagged management traffic breaks, and CDP/LLDP and any untagged protocol behave inconsistently. Worse, it creates a VLAN-hopping path: an attacker on an access port in VLAN 1 can send double-tagged frames assuming the trunk forwards the native VLAN untagged on the far side. Because unused ports are still in VLAN 1 and VLAN 1 is allowed on the trunk, the lobby switch has a viable foothold.
Fix in this order: shut and park unused ports, set both trunk ends to the same native VLAN (preferably an unused ID such as 999), prune VLAN 1 from the trunk and from access ports, and move management to a dedicated VLAN. Aligning the native VLAN is hygiene that closes an exposure, but it should be scheduled as security remediation, not sold as the DHCP fix.
3. The lobby switch and idle ports are still a live risk. Which Layer 2 protections would you enable, and what are the interactions between them?
Read the worked answer
BPDU guard on every edge port is the primary control: if a port receives a BPDU, it err-disables, which stops the unmanaged switch (or any rogue bridge) from joining the STP topology. Root guard on SW-D's downstream-facing ports complements this by preventing a rogue device from winning the root election and reshaping traffic paths.
Port security (switchport port-security maximum 2, sticky MAC learning, violation restrict or shutdown) limits MAC flooding and casual daisy-chaining, but it does not stop a bridge that forwards BPDUs, so it is not a substitute for BPDU guard.
Dynamic ARP inspection depends on the snooping bindings, so it must be enabled only after the trust configuration is correct; a wrong trust boundary makes DAI drop legitimate ARP and creates a second outage. Verify that the cleanup you just did (uplink trusted, access ports untrusted) is in place first. Then enable DAI on VLAN 10 and 30 with a validation check against DHCP.
Finally, configure errdisable recovery only after alerting exists, otherwise ports silently cycle; log to syslog and alert on %PM-4-ERR_DISABLE. Put the lobby ports in a dedicated VLAN or shut them, and document the change.