When a DHCP server stops handing out IP addresses, clients fall back to APIPA (169.254.x.x) and lose network access. The fix usually comes down to one of four things: an exhausted scope, a stopped DHCP service, a broken relay across VLANs, or a rogue DHCP server on the segment. Work through each in order.
Symptoms
- Clients receive a 169.254.x.x APIPA address instead of a valid LAN IP
- ipconfig /renew returns "unable to contact your DHCP server"
- Only wired or only wireless clients fail to get a lease; the other side works
- DHCP scope shows 100% utilization or every lease marked BAD_ADDRESS
- New devices fail while existing devices with cached leases still work
Common Causes
Scope exhaustion or short lease pool
Every address in the configured range is leased out or reserved. This is common after guest-Wi-Fi spikes or when lease times are set to several days on a busy /24.
DHCP service stopped or database corrupted
The DHCP Server service on Windows Server, dhcpd on Linux, or the router's built-in DHCP daemon has crashed, or the lease database is locked after an unclean shutdown.
Broken DHCP relay across subnets
Clients on a remote VLAN cannot reach the DHCP server because the ip helper-address on the SVI is missing, wrong, or blocked by an ACL upstream.
Rogue DHCP server on the segment
A second device, often a home router plugged in backwards or a misconfigured hypervisor, answers DISCOVER packets first and hands out unusable leases from a foreign subnet.
Layer-2 problem blocking DHCP traffic
DHCP snooping is enabled without trusted uplink ports, a switch port is err-disabled, or spanning-tree is still in listening state when the client requests a lease.
Step-by-Step Fix
- Confirm the client is actually trying DHCP, not stuck on a static entry
Run ipconfig /all on Windows or ip addr and cat /etc/netplan/*.yaml on Linux. Verify the interface is set to obtain an address automatically. A 169.254.x.x address confirms DHCP failed; a manually assigned address means the client never asked in the first place. - Capture the DHCP conversation on the wire
On the client, run ipconfig /release then ipconfig /renew while capturing with Wireshark filtered on bootp. You want to see DISCOVER, OFFER, REQUEST, ACK. Missing OFFER points to a server or relay problem. Multiple OFFERs from different IPs points to a rogue server. - Check the DHCP server scope and service state
On Windows Server open DHCP console and inspect Address Pool, Address Leases, and the Scope Statistics pane. If utilization is at or near 100%, either extend the scope, shorten the lease duration, or reclaim BAD_ADDRESS entries. Restart the DHCP Server service if the scope shows red. - Verify the relay path for remote subnets
If the affected clients are on a different VLAN than the DHCP server, log into the L3 switch or firewall serving that VLAN and confirm ip helper-address points to the correct DHCP server IP. Check any ACL between the VLAN and the server allows UDP 67 and 68 in both directions. - Hunt for a rogue DHCP server
From an affected subnet run dhcpdiscover -i eth0 (Linux dhcping/nmap --script broadcast-dhcp-discover) or Get-DhcpServerInDC on the domain. Any OFFER coming from an IP you do not recognize is the culprit. Trace its MAC through the switch CAM table and shut the port. - Inspect switch-level DHCP protections
If DHCP snooping is enabled, the uplink toward the DHCP server must be configured as trusted. Untrusted uplinks silently drop OFFER and ACK packets. Also check for err-disabled ports and enable portfast on access ports so clients do not time out during spanning-tree convergence. - Reconcile or rebuild the lease database
On Windows Server, right-click the scope and run Reconcile to fix inconsistencies between the registry and the database. For ISC dhcpd, stop the service, back up dhcpd.leases, remove stale entries with expiry dates in the past, and start the service again. - Validate end-to-end with a clean client
Plug a known-good laptop into the affected VLAN, request a lease, and confirm you receive an address from the correct scope, the right default gateway, and working DNS. Document the lease in your monitoring so the next occurrence is caught before users notice.
Common DHCP failure signatures and where to look first
| Symptom | Likely cause | First action |
|---|---|---|
| Client gets 169.254.x.x | No OFFER reached the client | Packet capture on the client port |
| Only remote VLAN fails | Missing or wrong ip helper-address | Check SVI config on L3 switch |
| Random clients get wrong subnet | Rogue DHCP server on the segment | Trace unknown OFFER MAC in CAM table |
| Scope shows 100% used | Lease exhaustion | Extend range or shorten lease time |
| Server logs "database corrupted" | Unclean shutdown of DHCP service | Restore from backup, then reconcile scope |
| OFFER seen but no ACK | ACL or firewall dropping unicast reply | Allow UDP 67/68 between client VLAN and server |
Prevention
- Alert on DHCP scope utilization above 80% in your monitoring system
- Enable DHCP snooping with trusted uplinks on every access switch
- Keep lease duration proportional to client turnover (8 hours for guest, 8 days for office)
- Document ip helper-address entries in your network diagram and review after every VLAN change
FAQ
How do I tell the difference between a DHCP problem and a DNS problem?
Run ipconfig on the client. If you see a 169.254.x.x address or no address at all, DHCP is failing. If you have a proper LAN IP and default gateway but websites do not resolve, it is DNS. A quick ping to 8.8.8.8 confirms Layer 3 works when name resolution does not.
Should I use short or long DHCP lease times?
Match the lease to how long devices actually stay on the network. Guest Wi-Fi with high turnover benefits from 2 to 8 hour leases so addresses recycle quickly. Office subnets with stable workstations can safely run 4 to 8 day leases, which reduces server load and log noise.
Can I run two DHCP servers for redundancy without conflicts?
Yes, but only with a supported split-scope or failover configuration. Windows Server supports DHCP failover in hot-standby or load-balance mode since 2012. ISC Kea supports high availability. Never simply enable DHCP on two independent devices with overlapping ranges; that produces duplicate leases and intermittent outages.
Book a network health check with our IT support team to audit your DHCP, DNS, and VLAN configuration.