This DHCP failure database is built around signatures, boundaries, and the next best artifact
DHCP problems are easiest to diagnose when you stop treating “no IP address” as a single failure. The client may fail before the request reaches the server, the server may have no usable address to offer, the wrong scope may answer, a relay may point to the wrong place, renewal may fail after the original lease worked, or an unauthorized server may respond first. Each signature narrows a different part of the path.
Know the normal transaction before diagnosing the abnormal one
Real implementations include more detail, but this four-step model gives students a useful reference point. A failure signature becomes much easier to interpret when you can say exactly where the expected exchange stopped or changed.
Use the observed clue to choose the next artifact
| Observed clue | Strongest boundary | Next evidence | Do not overclaim |
|---|---|---|---|
| Client gets APIPA | No usable DHCP lease acquired | Client lease state, DHCP logs, VLAN/relay path | Does not prove server is down |
| One VLAN fails | VLAN/relay/scope-specific path | Relay, trunk, SVI, scope state | Working VLANs prove some DHCP service exists |
| All VLANs fail | Shared DHCP/service path | Server, shared relay/routing, firewall | Look for a common dependency |
| No free addresses | Scope exhaustion | Active leases, pool size, exclusions | Rebooting does not create capacity |
| Wrong subnet lease | Wrong scope/VLAN/relay/source | Switch VLAN, relay, DHCP server identity | A lease can be valid yet wrong |
| Reservation ignored | Identity/binding mismatch | Reservation key and client request identity | Displayed NIC label may not be match field |
| Renewal fails | Lease lifecycle/path issue | T1/T2 timing, logs, server reachability | Current lease may still work temporarily |
| Unexpected offer | Rogue/wrong DHCP source | Packet capture, server identifier, gateway/DNS | Treat as security issue |
Swipe horizontally to see the DHCP evidence matrix.
Client receives APIPA / 169.254.x.x
The strongest first statement is not “DHCP server down.” The supported boundary is that the client did not obtain the expected usable IPv4 lease. The failure may be the client, access VLAN, DHCP relay, server path, scope availability, or policy.
All clients in one VLAN fail DHCP
This signature is much narrower than “DHCP is broken.” If other VLANs obtain leases from the same infrastructure, the server is demonstrably capable of serving at least some clients. Focus on the failed VLAN's relay/helper, trunk carriage, SVI, firewall path, and scope.
Every VLAN fails DHCP at once
When multiple previously healthy VLANs all lose DHCP at the same time, the scope widens. Shared dependencies become stronger: DHCP service state, routing to the server, common relay infrastructure, firewall policy, server interface, or a shared upstream failure.
Scope exhaustion: the request reaches the server but there is nothing left to lease
Scope exhaustion is one of the cleanest DHCP signatures when the server logs the incoming request and reports no free addresses. The troubleshooting task then changes from “why can't the client reach DHCP?” to “why has usable address capacity been consumed?”
Usable DHCP capacity is smaller than the subnet's raw address count
Network and broadcast addresses are not host leases. Static addresses, exclusions, infrastructure ranges, reservations, and design policy can further reduce the pool available to dynamic clients. Capacity analysis therefore needs the actual configured lease pool, not just the CIDR size.
Client receives an address from the wrong subnet
A wrong lease is often more informative than no lease. It proves that a DHCP exchange completed with some server or scope. The question becomes why this client was placed into that scope.
Separate VLAN placement from DHCP scope selection
If the switch or AP places the client in the wrong VLAN, DHCP may be doing exactly what it should for that VLAN. If the client is definitely in the correct VLAN but receives the wrong subnet, investigate relay information, server scope association, policy, or a rogue server.
Reservation is not honored
Reservations depend on the identity the server actually uses for matching. A technician may compare the wrong MAC address, overlook a client identifier, or configure a reservation in the wrong scope.
The label printed on the adapter may not be the only identifier that matters
Depending on the platform and server behavior, DHCP matching can involve a client identifier rather than simply the MAC address a technician expects. Wireless privacy features can also complicate assumptions about which MAC appears on a given network.
Renewal fails while the current lease still works
This signature catches students because the client may continue to communicate normally for a while. A valid existing lease can remain usable even though the renewal path has broken. Capture the state before the lease expires or the client changes behavior.
Lease lifecycle gives renewal failures a timeline
T1
The client first tries to renew with the original DHCP server.
T2
If renewal fails long enough, the client broadens its attempt to rebind.
Expiration
If no valid lease is recovered, the client can no longer keep using the expired address.
Rogue DHCP offer: the client receives plausible but unauthorized configuration
A rogue DHCP server may hand out an address that looks normal enough to fool casual troubleshooting while supplying an unauthorized gateway, DNS server, subnet, or lease parameters. This is both a reliability and security issue.
Packet or log evidence can identify the server that sent the offer
Do not stop at “wrong settings.” Capture the offer, identify the DHCP server identifier or source, trace its Layer 2 location if possible, and determine whether it is an unauthorized device, misconfigured appliance, test system, or unexpected secondary server.
The DHCP server responds to ping, but the client still gets no lease
ICMP reachability proves only that some IP path to the server exists from the system doing the ping. DHCP depends on UDP service, broadcast/relay behavior, scope logic, policy, and the client's actual path. A successful ping therefore leaves many DHCP-specific dependencies unresolved.
The same client gets a lease after moving to another port
Keep the endpoint constant and change only the access path. If the client immediately leases successfully on a known-good port, the original port's VLAN assignment, port state, local policy, cabling, or switch configuration becomes much stronger.
DHCP relay is the bridge between broadcast clients and remote servers
Initial DHCP traffic begins locally, but enterprise DHCP servers are often on another routed network. A relay receives the client broadcast and forwards the request toward the server with information that helps the server choose the proper scope.
Relay problems often look like a healthy server with one broken subnet
If the DHCP server leases successfully to directly connected or other relayed networks but never sees requests from one VLAN, inspect that VLAN's SVI/helper, routing, ACL/firewall path, and VLAN carriage before blaming the server.
One DHCP server can serve many VLANs, but each VLAN still has its own logical path
This is why scope comparison is so powerful. A shared DHCP service can be healthy while one VLAN fails because its relay, scope, or trunk path is wrong.
Wrong SSID-to-VLAN mapping can create a DHCP symptom that is not really a DHCP failure
If a Staff SSID accidentally maps to the Guest VLAN, the DHCP server may correctly lease a Guest address. The client sees “wrong IP,” but the root cause sits earlier in wireless-to-VLAN placement.
Distinguish genuine capacity exhaustion from stale or inappropriate lease use
Before expanding the scope, inspect active leases, lease duration, exclusions, reservations, abandoned/conflict-marked addresses where applicable, and whether unexpected devices are consuming addresses. Capacity changes should respect the subnet boundary and static infrastructure plan.
Find the first DHCP stage that diverges from expected behavior
| Observed sequence | Meaning |
|---|---|
| No client request visible anywhere | Client/access/link/VLAN stage remains suspect |
| Relay sees request; server never does | Relay-to-server path/policy/routing stronger |
| Server sees request; no offer | Server/service/scope/availability stronger |
| Offer sent; client never receives it | Return path/VLAN/policy stronger |
| Lease completes but config is wrong | Scope/options/VLAN/source selection stronger |
Swipe horizontally to see the failure sequence.
APIPA on one laptop, peers lease normally
The working peers make a total DHCP-server outage a weak explanation.
One classroom VLAN fails while the rest of the school leases normally
Scope exhaustion only during the morning arrival window
This is stronger than randomly shortening lease duration without understanding when and why address demand peaks.
Clients receive valid addresses but the wrong gateway and DNS
Renewal fails after a firewall change
Because the original lease still works, capture evidence before expiration changes the client state.
A DHCP fix is verified only when the full intended configuration returns
Do not stop when the client receives any address. Confirm the correct subnet, prefix, gateway, DNS servers, lease source, and required connectivity. If the problem involved segmentation, verify that the client did not merely receive a lease on the wrong network.
Strong answers name the DHCP boundary without claiming more than the evidence supports
If a client has APIPA, say it failed to acquire the expected DHCP lease—not that the server is definitely offline. If other VLANs lease successfully, say the server can serve some clients and narrow toward the failed VLAN's scope/relay/path. If the server logs NO_FREE_LEASES, scope exhaustion is directly supported.
24 DHCP Failure Signatures digital flashcards
Practice DORA, APIPA, scope exhaustion, one-VLAN vs all-VLAN failures, relay behavior, wrong scopes, reservations, T1/T2 renewal, rogue DHCP, evidence boundaries, and verification.