Intermittent APIPA Addresses After DHCP Failover
A regional office has 180 wired clients on VLAN 40, using subnet 10.40.0.0/24. Two DHCP servers are configured for load-balancing failover with an 8-day lease; the scope is 80% utilized. After a brief power event, about 30% of wired clients on floor 3 self-assign 169.254.x.x addresses. Wireless clients on the same VLAN still receive addresses. The affected floor connects through a 48-port access switch whose uplink is a trunk to the core; a new unmanaged 5-port switch was recently added under a desk to connect five workstations. Users report intermittent connectivity and Windows duplicate-address warnings. A capture on one affected PC shows repeated DHCPDISCOVER messages with no DHCPOFFER; ARP for 10.40.0.1 succeeds. The access switch shows no err-disabled ports, but CPU is elevated and MAC address flapping is logged on two ports. The core SVI for VLAN 40 has helper addresses pointing to both DHCP servers.
1. Rank the likely causes and describe the first three troubleshooting steps.
Read the worked answer
Most likely: a broadcast storm or loop from the unmanaged switch, with DHCP relay or server failover as secondary checks. The clues are localized to wired floor 3, wireless on the same VLAN works, the PC sends DHCPDISCOVER but gets no offer, ARP to the gateway works, and the access switch shows high CPU with MAC flapping on two ports. That pattern points to a Layer 2 loop or storm dropping broadcast DHCP traffic, not a dead DHCP server.
First, identify the two flapping ports and remove the unmanaged switch; check interface broadcast counters and CPU. Second, confirm the core SVI for VLAN 40 has the correct helper addresses and that both DHCP servers show the failover state as normal. Third, renew on a test PC and capture on the core SVI to see whether DHCPDISCOVER reaches the server. Only then investigate duplicate-address warnings, which may be a separate DHCP snooping or ARP issue.
2. How would you distinguish a DHCP relay failure from a broadcast storm as the primary cause?
Read the worked answer
Use the scope of the failure and the path of the DHCP packet. A relay failure would affect all wired VLAN 40 clients, including wireless clients on the same VLAN, because the core SVI is the common relay. Here wireless works, so the relay and DHCP servers are probably functional. A broadcast storm fits the localized floor, MAC flapping, and high CPU.
To prove it, capture on the access switch uplink and on the core SVI: if DHCPDISCOVER is present on the access port but absent or delayed at the core, the storm or loop is dropping it. If DISCOVER reaches the server and no OFFER returns, check server scope, failover state, and lease exhaustion. Also check the DHCP server logs for requests from the floor 3 relay giaddr. ARP success only proves the gateway is reachable, not that broadcast DHCP traffic is flowing.
3. What permanent changes would you make to prevent recurrence, including DHCP design changes?
Read the worked answer
Permanent controls: remove the unmanaged switch and disable unused access ports. Enable BPDU Guard or Filters, Root Guard on core-facing ports, storm control, and port security MAC limits. Configure DHCP snooping and Dynamic ARP Inspection on VLAN 40 to stop rogue DHCP and duplicate-address or ARP problems; rate-limit DHCP on access ports. Put the native VLAN on an unused ID and prune it from trunks.
Address the DHCP design too: 80% scope utilization with 8-day leases leaves little room after an outage; shorten the lease, expand or split the scope, and verify failover partner roles and load-balance percentages. Add monitoring for MAC flapping, broadcast rate, and DHCP pool utilization. Finally, document an access-port recovery procedure so BPDU Guard err-disables do not turn into prolonged outages.