“No DHCP address” is a symptom, not a diagnosis
A client can fail to obtain a useful lease because the request never leaves the endpoint, enters the wrong VLAN, dies before a relay, reaches a server that cannot offer an address, loses the return exchange, or completes DHCP using the wrong scope.
Before changing anything, inspect the active interface. Is DHCP enabled? Is there a normal IPv4 address, no address, 0.0.0.0-style unconfigured state, or a 169.254/16 link-local address? Which adapter are you viewing? Does Ethernet show link or Wi-Fi show association? What subnet should this device belong to?
A 169.254/16 address is useful evidence: normal IPv4 assignment did not complete and the client fell back to link-local addressing. It does not tell you whether the cause is DHCP server failure, exhausted scope, wrong VLAN, missing relay, filtering, NAC, or a client-specific problem.
Use the last successful DHCP stage to place the failure boundary
Do not memorize DORA as four vocabulary words and stop there. Treat it as a diagnostic timeline. If a server log never sees Discover, investigate before the server. If Discover arrives but no Offer leaves, investigate server service, scope selection, capacity, and policy. If Offer leaves but the client never sends Request, investigate delivery back to the client and client acceptance/state. If Request arrives but no ACK is generated, investigate server-side processing and eligibility. If ACK leaves but the client still has no usable configuration, investigate the return path and client application of the lease.
One client and one VLAN are completely different DHCP problems
One client fails
If fresh peers on the same VLAN obtain leases, focus on that endpoint, adapter, DHCP setting, port/association, authentication/NAC state, or client-specific filtering.
One VLAN fails
If every new client in VLAN 30 fails while other VLANs lease normally, inspect VLAN 30's SVI/relay, trunk/access placement, scope, and segment-specific policy.
All clients fail
A broad failure raises server/service availability, shared DHCP infrastructure, common path/policy, or a wider configuration change.
A known-good peer is one of the highest-value controls. Compare the affected device with a client that should use the same VLAN, relay, scope, and DHCP server. Differences can shrink the hypothesis set quickly.
DHCP can fail before a router or server ever becomes relevant
The initial client search depends on correct local attachment. Ethernet link-up proves a physical/link state, not correct VLAN membership. Wi-Fi association proves the client joined an access point, not necessarily that authentication completed or that the SSID maps to the intended VLAN.
For a single wired client, compare access-port mode and VLAN with a working peer. For wireless, compare SSID, authentication/NAC outcome, VLAN assignment, and whether another client on the same SSID receives the expected subnet. If the client is placed into the wrong VLAN, DHCP may actually succeed—from the wrong scope. That is a configuration failure even though DORA completed.
A remote DHCP server needs subnet context, not just IP reachability
Routers do not normally forward the client's local broadcast unchanged to a DHCP server on another subnet. A DHCP relay/helper receives the local request and forwards it toward the server while supplying information that lets the server associate the request with the originating subnet.
This explains a classic post-segmentation failure: DHCP worked when clients and server shared a broadcast domain, but stops after clients move behind a routed boundary. The server itself may be healthy and reachable by unicast while the client discovery path is incomplete.
Check that the relay exists on the correct client-facing Layer 3 interface, points toward the intended server, and that routing/policy permits the relayed exchange. Also verify the server has an eligible scope corresponding to the relayed subnet context. A relay that forwards with the wrong context can produce “server reachable, no useful Offer.”
The server must choose an eligible scope for the client’s network
A DHCP server can be running normally yet decline to offer a lease because no appropriate scope is active for the client context. Check the intended network/prefix, scope activation, exclusions, reservations/policies where applicable, and whether the relay context maps the request to the expected subnet.
This is why “the DHCP service is up” is weak evidence. Service health does not prove the server can satisfy this client's request. The useful question is whether the server received this request, associated it with the correct network, found an eligible address, and generated an Offer.
Scope exhaustion has a distinctive evidence pattern
If the correct scope has zero usable addresses available for new clients, the server may be perfectly healthy but unable to issue a new lease. Inspect active leases, free-address count, exclusions, reservations, lease duration, and expected client population.
Do not assume every active lease is stale. First compare utilization with legitimate demand. A classroom with 120 addresses and 118 active devices is a different problem from a 250-address scope with hundreds of unexpected leases. Shortening lease duration blindly can mask poor sizing; expanding a scope blindly can hide unauthorized or mis-segmented clients.
For a focused capacity lab, use DHCP Scope Exhaustion.
When peers work, inspect what is unique about the endpoint
Confirm the active adapter is configured for DHCP rather than manual addressing. Verify you are not reading a VPN, virtual adapter, disconnected Ethernet interface, or another interface unrelated to the failing path. Check whether the client passed 802.1X/NAC requirements and whether local security software or adapter state differs from a working peer.
Renew/release operations can be useful, but collect the current state first. A blind release can erase lease details that would have shown the wrong DHCP server, wrong subnet, or stale configuration. Preserve evidence before resetting it.
DHCP protections can fail selectively when trust boundaries are wrong
ACLs, firewalls, DHCP snooping/protection features, NAC, or security policy can interfere with parts of the exchange. The right fix is not “allow UDP everywhere.” Identify which DHCP message fails to traverse which expected boundary.
For example, if Discover reaches the relay and the server logs a generated Offer, but the client never sees that Offer, the evidence shifts toward the return path and policy/security features between server, relay, switching infrastructure, and client. If only one switch or access area fails, compare its trust and VLAN configuration with a working area.
Security controls should be corrected narrowly so legitimate DHCP works without enabling rogue server behavior or unnecessary traffic.
A capture turns “DHCP is broken” into a stage-by-stage observation
| Observed pattern | What it supports | High-value next branch |
|---|---|---|
| No Discover on client interface | Normal DHCP attempt not observed | Client DHCP state, adapter, capture point |
| Discover on client, absent at relay/server | Client generated request | VLAN, Layer 2 path, relay, filtering |
| Discover at server, no Offer | Request reached server | Scope eligibility/capacity, policy, service processing |
| Offer generated, no Request | Server attempted response | Return delivery, client acceptance/state |
| Request reaches server, no ACK | Client selected/requested configuration | Server processing, lease/policy, ACK generation |
| ACK observed, client wrong subnet | Lease exchange completed | Wrong VLAN/scope/relay context or client application |
Swipe horizontally to see the full table.
A valid-looking address from the wrong network is a different failure signature
Do not stop at “the client got an IP.” Compare the lease to the intended segment. If a device on the Staff SSID receives a Guest subnet, the DHCP exchange may be functioning exactly as the network path instructed it to. The problem may be SSID-to-VLAN mapping, access-port assignment, trunk/native behavior, relay context, or server scope selection.
This distinction matters because troubleshooting the DHCP server itself may waste time. A wrong lease can be strong evidence about segmentation. Compare the affected client's VLAN/SSID path with a known-good client and inspect which server/scope supplied the lease.
Example: every new client in VLAN 40 self-assigns 169.254 addresses
Assume existing VLAN 40 users with old leases still communicate, but every new VLAN 40 client gets 169.254/16. VLAN 20 and VLAN 30 continue receiving leases. That scope makes a total DHCP-server outage unlikely.
The client evidence proves Discover generation. The absence at the server moves the boundary into the path between VLAN 40 and DHCP infrastructure. Other VLANs prove the server can process leases. The missing relay on VLAN 40's Layer 3 interface directly fits the failure. The narrow repair is to restore the intended relay configuration—not restart DHCP or change client DNS.
Verification should use a fresh VLAN 40 client, confirm full DORA, inspect the resulting subnet/gateway/DNS values, and then test the original network requirement.
A lease is successful only when it is correct and usable
After repair, inspect more than the presence of an address. Confirm the IPv4 address belongs to the intended subnet, the mask/prefix is correct, the default gateway is appropriate and locally reachable, DNS options are expected, and the lease came from the intended DHCP infrastructure where that evidence is available.
Then test the original task. If the incident was scope exhaustion, verify a fresh client can lease and inspect remaining capacity. If the incident was relay failure, verify clients in that subnet while confirming other subnets still work. If the incident was security policy, verify legitimate DHCP while preserving the intended protection against unauthorized DHCP behavior.
24 DHCP troubleshooting flashcards built around evidence
Use these cards to practice DORA stages, failure scope, relay behavior, scope capacity, client state, VLAN mistakes, security controls, and verification. They are designed to make you choose a diagnostic branch rather than merely recite DHCP definitions.
Be careful not to turn the absence of a DHCP address into a diagnosis before locating the failed dependency. The client could have a link, successful wireless association, and a functioning NIC while DHCP fails because of VLAN placement, relay configuration, server reachability, scope state, or policy. The Evidence Ceiling guide for network troubleshooting teaches students how to preserve those successful checkpoints instead of incorrectly labeling the entire network path as broken.
Five DHCP conclusions that are too broad
“169.254 means the DHCP server is down.”
No. It shows normal IPv4 configuration failed; many client, VLAN, relay, path, scope, and policy causes remain.
“The server is pingable, so DHCP should work.”
Unicast IP reachability does not prove the client broadcast/relay process, scope selection, or DHCP policy.
“The client got an IP, so DHCP is fixed.”
A wrong-scope lease can be evidence of VLAN or relay-context failure.
“Wi-Fi says connected, so Layer 2 is fine.”
Association does not prove intended VLAN placement, NAC success, or a working DHCP path.
“Restart the DHCP server.”
A restart does not fix exhausted capacity, wrong VLANs, missing relays, or incorrect client settings.
Use this order when the prompt gives little evidence
First establish the active interface and whether normal DHCP configuration is absent. Second determine failure scope with a known-good peer. Third identify the last successful DORA stage using client capture, relay evidence, or server logs when available. Fourth inspect the dependency immediately after that stage: local VLAN/path before server visibility, server scope/capacity after Discover arrives, return/client behavior after Offer, or server processing after Request. Fifth make the smallest justified correction. Finally verify the lease fields and original requirement.
This sequence is more efficient than testing every networking layer because each step is chosen from the evidence already available. For the broader troubleshooting framework, use the AP Networking Troubleshooting Guide. For DHCP concepts outside this symptom, use DHCP Explained.
Renewal success can hide a failure that affects only brand-new clients
DHCP incidents can look contradictory when existing clients keep working while new clients fail. An endpoint with a valid lease may continue using its configuration and later attempt renewal without reproducing the exact path used by a client starting from no lease. That means “my existing laptop still works” does not prove that new-client address assignment is healthy.
This distinction is especially useful during scope exhaustion, relay changes, VLAN migrations, or policy changes. Compare at least one client that already holds a valid lease with a genuinely fresh lease attempt. If existing clients communicate but new clients cannot obtain addresses, investigate capacity and the initial lease path rather than treating the working clients as proof that DHCP is fully operational.
When verifying a repair, use the test that matches the original failure. If new arrivals could not get addresses, a successful renewal by an old client is weaker evidence than a fresh client completing the full exchange and receiving the intended options.
More than one DHCP responder can create wrong leases instead of missing leases
Not every DHCP incident is silence. A client can receive an Offer from an unintended DHCP server and end up with a plausible-looking address, gateway, or DNS configuration that belongs to the wrong design. This can produce inconsistent symptoms when different clients accept different Offers.
When the evidence shows unexpected lease parameters, inspect the DHCP server identifier or other available lease/server evidence and compare it with the authorized infrastructure. Determine whether the client is in the wrong VLAN or whether an unauthorized/incorrect DHCP responder is reachable on the segment. These are different mechanisms: one changes where the client is attached; the other changes who is answering.
Security features such as DHCP snooping are intended to help control which ports may originate server-side DHCP traffic, but their configuration must match the actual topology. Verification should confirm that authorized DHCP still works and unintended server responses are not accepted through paths that should be untrusted.