DHCP is a configuration system, not just an IP-address dispenser
Dynamic Host Configuration Protocol can assign an IPv4 address, subnet mask or prefix information, default gateway, DNS resolver addresses, lease duration, and other options. That changes how you troubleshoot it. A client with no address may have a DHCP-path problem, but a client with a perfectly normal-looking address can still have a DHCP-originated failure if the gateway or DNS options are wrong.
Continue from the allocation sequence with AP Networking DHCP Leases and Relays Practice Test. Its separate difficulty sets distinguish initial selection, remembered-address validation, original-server renewal, rebinding and expiration, then check the effective settings a client actually applied.
Turn DORA knowledge into a diagnosis with the AP Networking DNS, DHCP, and Protocols Practice Test. Its questions distinguish an offer sent from an offer received, a completed lease from correct options, and a reachable server from a correctly relayed client network.
Discover, Offer, Request, ACK becomes powerful when each stage is treated as evidence
| Stage | Typical actor | What it proves | If the exchange stops here |
|---|---|---|---|
| Discover | Client | The client is actively looking for DHCP service | Inspect local VLAN/broadcast path, relay, filtering, and server reachability |
| Offer | Server | The server received enough information to propose configuration | Inspect return path, relay handling, client reception, competing offers |
| Request | Client | The client selected/requested an offered configuration | Inspect server state, transaction continuity, and ACK generation |
| ACK | Server | The server confirmed the lease | If service still fails, inspect lease options and later network layers |
Swipe horizontally to see the full DORA table.
A capture can reveal the exact last successful DHCP stage
Hypothetical capture 08:15:01.102 Client → Broadcast DHCP Discover 08:15:01.134 Server → Client DHCP Offer 10.20.30.57 08:15:01.151 Client → Broadcast DHCP Request 10.20.30.57 08:15:01.170 Server → Client DHCP ACK 10.20.30.57 Options carried in lease: Address: 10.20.30.57 Mask: 255.255.255.0 Gateway: 10.20.30.1 DNS: 10.20.5.53
This hypothetical sequence supports a completed lease transaction. It does not prove that the gateway is the intended gateway, that DNS is reachable, or that the user's application works. The capture becomes useful when you connect the completed stage to the original failure.
The client does not need to know the DHCP server's IP before starting
Initial DHCP behavior is designed for a device that does not yet have normal IPv4 configuration. On the local network, the client can begin with broadcast behavior. If the server sits on another routed network, a relay must bridge that discovery process into a unicast/routed path toward the server.
The scope defines what a server is allowed to offer
A scope normally contains an address range plus the options appropriate for one subnet or logical client population. Exclusions keep selected addresses out of the dynamic pool. Reservations can give a known client a predictable lease. Scope data is therefore both configuration and evidence.
Hypothetical scope Subnet: 10.20.30.0/24 Dynamic pool: 10.20.30.50 - 10.20.30.200 Exclusions: 10.20.30.1 - 10.20.30.49 Gateway: 10.20.30.1 DNS: 10.20.5.53 Free leases: 3
A server can be powered on, reachable, and otherwise healthy while this scope is nearly unable to support new clients.
Existing clients can work while every new client fails
If the address pool is exhausted, clients that already hold valid leases may continue communicating while new devices cannot obtain a usable address. That pattern is far more informative than a generic “DHCP is broken” report.
| Observed pattern | What it suggests | Next discriminating evidence |
|---|---|---|
| Old clients work; new clients fail | Lease capacity or DHCP-specific failure remains plausible | Scope utilization and free-address count |
| Only one VLAN fails | VLAN/relay/scope-specific cause | That VLAN's scope and relay path |
| Server answers management traffic | Server is broadly reachable | DHCP-specific service/scope state |
Swipe horizontally to see the full table.
For the dedicated failure mode, continue with DHCP Scope Exhaustion.
DHCP outages may emerge gradually instead of all at once
Leases are time-bounded. Clients normally try to renew before expiration. If the DHCP service later becomes unavailable, a device with a still-valid lease can continue using its assigned settings for a period. A newly connected device may fail immediately while a long-running desktop appears completely normal.
That means “several users are still online” is not a strong DHCP health check. A better test is to observe a new lease or renewal transaction from the affected network.
A successful DORA exchange can deliver bad network configuration
Suppose a client correctly receives 10.20.30.57/24 but the DHCP router option points to 10.20.30.254 when the intended gateway is 10.20.30.1. Same-subnet traffic may still work while remote traffic fails. Or the gateway can be correct while an incorrect DNS option causes hostname failures even though numeric IP access works.
A known-good peer can expose the one option that differs
Working client Failing client IP: 10.20.30.61 IP: 10.20.30.62 Mask: 255.255.255.0 Mask: 255.255.255.0 Gateway: 10.20.30.1 Gateway: 10.20.30.254 DNS: 10.20.5.53 DNS: 10.20.5.53
If both clients are intended to use the same VLAN and scope, the gateway difference is high-value evidence. The working peer also tells you the shared VLAN and upstream network can support the required traffic, so replacing cables or rewriting routes becomes less justified.
A relay carries the DHCP transaction across a Layer 3 boundary
Client in VLAN 10
│ Discover (local broadcast)
▼
VLAN 10 gateway / DHCP relay
│ forwarded request
▼
Remote DHCP server
│ Offer / ACK through relay path
▼
Client in VLAN 10The relay also supplies information that helps the server select the appropriate client scope. A relay mistake can therefore break DHCP for exactly one VLAN even though the central DHCP server continues serving several others.
One-VLAN failure is evidence against a simple “server is down” conclusion
| Evidence | Reasonable inference | Next artifact |
|---|---|---|
| VLAN 20 and 30 lease successfully; VLAN 10 does not | Shared server can serve at least some clients | VLAN 10 relay, scope, VLAN path |
| Discover reaches relay but never server | Client-side local broadcast path works to relay | Relay forwarding, route, ACL/firewall |
| Server generates Offer; client never sees it | Server can respond | Return relay path, VLAN delivery, filtering |
Swipe horizontally to see the full relay table.
A 169.254/16 address is a clue, not a root cause
A Windows-style client may assign itself an IPv4 link-local address from 169.254.0.0/16 when normal IPv4 configuration is unavailable. That tells you the expected assignment process did not complete. It does not prove that the server is offline.
Wrong VLAN, failed relay, exhausted scope, filtering, server failure, or client state can all fit that observation. Use APIPA Explained for the focused interpretation.
New clients fail while existing clients remain online
A classroom adds twelve laptops. Existing desktops continue using the network, but every new laptop falls back to 169.254 addresses. The server is reachable. Scope statistics show no free addresses.
Bounded diagnosis: scope exhaustion prevents new leases. Smallest change: correct the scope-capacity problem without creating address overlap. Verification: confirm new clients complete DORA and monitor free-address headroom.
Only one VLAN fails because its relay path is wrong
Clients in VLAN 20 and VLAN 30 receive leases from the same central DHCP server. VLAN 10 clients transmit Discover frames, but the server receives nothing for VLAN 10. The VLAN 10 gateway has an incorrect relay target.
The working VLANs preserve the server as at least partially known-good. Fix the VLAN 10 relay configuration, then verify with a fresh client in VLAN 10 rather than testing from a VLAN that was already working.
The client receives a lease, but a wrong gateway breaks remote connectivity
A client receives 10.20.30.57/24 and can reach another host in 10.20.30.0/24, but it cannot reach a remote subnet. Its lease lists gateway 10.20.30.254. A known-good peer on the same intended scope uses 10.20.30.1.
This is not a failed DORA exchange. It is a successful lease containing a bad option. Correct the router option and verify both lease content and the original remote service.
Numeric IP works but hostnames fail after renewal
A user renews a lease and suddenly cannot open a server by hostname. The same server still works by numeric IP. The failing lease shows a different DNS resolver from working peers.
That successful numeric-IP test preserves the routed path and moves the unresolved boundary toward DNS configuration. A route change would not be evidence-based; correcting the DHCP DNS option would be.
A known-good static configuration works when DHCP does not
A troubleshooting laptop in VLAN 40 cannot get a lease. When given a documented valid static address, prefix, gateway, and DNS, it reaches the required service. This does not reveal the precise DHCP fault, but it demonstrates that the tested link, VLAN path, gateway, and application path can work independently of DHCP.
The next branch is DHCP-specific: client transaction, relay, scope eligibility/capacity, server response, or filtering.
The last successful stage tells you which dependency to inspect next
| Last evidence | What is known | First unresolved boundary |
|---|---|---|
| No Discover | No request observed | Client/NIC/VLAN/local state |
| Discover leaves client | Client is requesting service | VLAN/relay/path to server |
| Server receives Discover | Forward path reached server | Scope/server eligibility and response |
| Offer generated | Server can propose a lease | Return path/client reception |
| Request arrives | Client selected requested configuration | ACK/server transaction state |
| ACK received | Lease completed | Lease values and downstream service |
Swipe horizontally to see the complete localization table.
Each DHCP artifact proves less than students often assume
| Artifact | Supports | Does not alone prove |
|---|---|---|
| 169.254 address | Normal assignment did not complete | Server is down |
| Discover observed | Client started DHCP | Server received it |
| Offer observed | Server proposed configuration | Client accepted it |
| ACK observed | Lease transaction completed | Gateway/DNS/service correctness |
| Valid-looking address | Client has an address | Correct scope or options |
| Static config works | Tested non-DHCP path can work | Exact DHCP root cause |
Swipe horizontally to see the full evidence table.
Generic reachability to the DHCP server does not prove DHCP traffic is permitted
ACLs, firewalls, switch security features, or relay-path policy can interfere with DHCP traffic while management pings or other protocols still work. The correct artifact is protocol-specific: DHCP packet capture, relay evidence, or matching rule/log counters.
Seven DHCP statements that are too broad
- “DHCP only assigns an IP.” It can assign several critical network options.
- “Existing clients work, so DHCP is healthy.” Existing leases can remain usable for a while.
- “The server pings, so DHCP must work.” DHCP depends on protocol-specific paths, relay, scope state, and policy.
- “169.254 means the server is off.” It only proves normal configuration did not complete.
- “ACK means the Internet must work.” The gateway or DNS options can still be wrong.
- “One VLAN failing means the whole DHCP server is down.” A relay/scope/VLAN-specific failure may affect only one segment.
- “A valid address rules out DHCP.” Bad options can still make DHCP the source of the failure.
Write DHCP answers from protocol stage, scope, and evidence—not from symptoms alone
Observation: what does the client show, and who else is affected?
Last completed stage: Discover, Offer, Request, or ACK?
Mechanism: what dependency is required for the next stage?
Evidence boundary: what has not yet been proven?
Next artifact: client config, packet trace, relay, scope, lease, or server log.
Smallest justified change: fix the specific supported cause.
Verification: prove the lease values and the original required service.
Receiving an address is only the first verification checkpoint
After a repair, obtain or renew a lease under the same relevant conditions. Verify the expected IP range, prefix/mask, default gateway, DNS resolver, and any other required option. Then test the original service. If the issue was scope exhaustion, also verify free-address headroom. If the issue was a relay, test from the affected VLAN rather than a network that was already healthy.
24 DHCP digital flashcards
Practice DORA, scope capacity, leases, options, relay, APIPA, evidence boundaries, failure localization, and verification. Before revealing the answer, name the artifact that would prove your claim.
Connect DHCP to addressing, VLANs, DNS, gateways, and troubleshooting
Read the evidence. Make a decision. Check your reasoning.
Use these connected resources to move from an explanation to a real networking decision.