Quick diagnosis: what this problem is really testing
Diagnose DHCP failures by identifying exactly where Discover, Offer, Request, or Acknowledge breaks. The key is to treat every command result, packet, address, route, VLAN, or timeout as evidence. A useful diagnosis explains both what the evidence proves and what it does not prove.
After following DORA, use AP Networking DHCP Leases and Relays Practice Test to compare the exchanges that occur later in the lease lifecycle. A new client’s successful allocation does not demonstrate an aging client’s unicast renewal path or prove that old option values have been replaced.
Once you have identified the last observed message, use the AP Networking DNS, DHCP, and Protocols Practice Test to decide which capture or configuration check comes next. The 75 items include relayed exchanges, scope exhaustion, unauthorized offers, and client settings that differ from the proposed lease.
Start with the exchange, not the error message
A device that cannot obtain an address may show a 169.254 address, no IPv4 address, or a generic connected-without-internet warning. Those symptoms tell you address assignment did not finish; they do not tell you why. The fastest way to reason through the problem is to reconstruct the expected DHCP exchange: the client broadcasts DHCPDISCOVER, a server returns DHCPOFFER, the client sends DHCPREQUEST, and the selected server completes the lease with DHCPACK. Each missing step points toward a different part of the path. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
When Discover is the last packet you see
If a capture shows repeated Discover messages but no Offer, the client is asking correctly and nobody is answering. Check whether the client is in the intended VLAN, whether the DHCP server is available, whether the scope has usable addresses, and—when the server is on another subnet—whether a relay forwards the broadcast. A DNS change will not repair this stage because the client has not yet received basic IP configuration. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
When Offer appears but Request does not
An Offer proves much more than many students realize: the request reached a DHCP service and a reply returned to the client segment. If the client never follows with Request, focus closer to the client: multiple offers, client software, an unexpected server, or a capture that is missing traffic. Do not jump backward and blame the server for being unreachable; the Offer is evidence that it was reached. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect. See also CLI output practice and find the network misconfiguration.
When Request appears but ACK does not
A Request without an ACK means the conversation advanced farther. The server may reject the requested lease, the return path may fail, or a policy may prevent completion. Look for DHCPNAK as well as silence. A NAK is active evidence: a server is telling the client that the requested configuration is not valid on that network. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Read the lease as evidence
After a successful ACK, inspect the assigned address, mask or prefix, default gateway, DNS servers, lease duration, and DHCP server. A lease can complete and still deliver a bad option. That is a different failure from 'DHCP is down.' If the address is correct but the gateway is wrong, DHCP worked mechanically while its configuration produced a routing problem. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
Separate one-client failures from whole-subnet failures
Scope matters. One failed laptop beside twenty working devices points toward that client, cable, switch port, authentication, or local configuration. Every new device failing on the same VLAN points toward shared infrastructure such as the scope, relay, VLAN path, or DHCP service. Good troubleshooting uses the number and location of affected devices before changing anything. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
A practical command sequence
On Windows, ipconfig /all reveals whether DHCP is enabled and which values were received. A release and renew can trigger a new exchange, but the command is a test—not a magic fix. On macOS or Linux, interface and lease tools vary, so focus on the same evidence: current address, route, DNS settings, and whether a new DHCP conversation completes. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect. Reinforce this with Wireshark packet-capture practice and network log analysis practice.
Packet-capture clues worth recognizing
Filter for DHCP/BOOTP traffic and read the message type in order. Repeated Discovers with increasing time gaps show retries. Offers from an unexpected server can reveal a rogue or misconfigured DHCP source. A Request that names a server identifier helps show which Offer the client selected. The capture turns a vague complaint into a timeline. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Common wrong turns
Do not assign a random static address just to make the warning disappear. That can create a duplicate address and hide the actual DHCP failure. Do not reset every network setting before recording evidence. And do not call every 169.254 symptom a DNS problem simply because browsers fail; without a usable address and route, DNS is downstream of the real failure. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
Exam-style reasoning
When a scenario gives you command output and a short capture, state what the evidence proves before naming a cause. 'No Offer follows repeated Discover broadcasts' is stronger than 'DHCP is broken.' Then choose the next test that separates plausible causes—for example, verify VLAN membership or relay configuration rather than changing DNS. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Evidence ladder: what to check before you change anything
| Evidence | What it can establish | What it cannot establish alone |
|---|---|---|
| IP configuration | Address, prefix/mask, gateway and DNS settings | That the path beyond the local device works |
| Ping | Whether a particular target replies to ICMP echo | That every protocol or application works |
| ARP/MAC evidence | Local Layer 2 discovery and switching clues | End-to-end routing or DNS health |
| Packet capture | Which messages were actually observed | Traffic that the capture point could not see |
Free interactive troubleshooting check
Read the three prompts. Predict the best reasoning move, then reveal the coaching answer.
- Scenario 1: The first test fails. What should you do next?
- Scenario 2: A later-hop or downstream test succeeds. What does that tell you?
- Scenario 3: Only one device is affected. Where should your investigation lean first?
Practice task: build a defensible diagnosis
Create a four-column evidence sheet labeled Observation, What it proves, What it does not prove, and Next test. Use at least five pieces of evidence from this guide. Then explain your diagnosis in 100–150 words without using the phrase “it is probably” unless you name the evidence supporting that probability.
Continue with AP Networking scenario questions, free-response practice, and configuration analysis practice.
Frequently asked questions
Should I memorize a fixed troubleshooting order?
Learn a dependable baseline, but let evidence change the order. A packet capture or command output may immediately rule out several layers.
Is one successful ping enough?
No. It proves a specific exchange succeeded at that moment. It does not prove DNS, TCP ports, applications, or every path is healthy.
What makes an AP Networking explanation strong?
Connect the symptom to a mechanism, cite the evidence, and choose a next test that can distinguish between remaining causes.
Teacher and student extension: compare two competing explanations
Take one failure scenario from this page and write two explanations that could both fit the first symptom. For each explanation, identify one piece of evidence you would expect to see if it were correct and one result that would weaken it. Then choose the single next test that gives you the most useful separation between the two explanations. This is the habit that turns troubleshooting from guessing into diagnosis.
For students, the goal is not to use the most commands. The goal is to ask the smallest number of useful questions. For teachers, this makes an effective five-minute warm-up: give students the symptom first, reveal one artifact at a time, and require them to revise their hypothesis as evidence arrives. A student who changes an answer because new evidence demands it is demonstrating stronger networking reasoning than a student who guessed the final cause immediately.
Finish by drawing the packet path from source to destination. Label the endpoint, local switch or wireless connection, VLAN or subnet boundary, default gateway when required, and any service involved in the failure. Mark where your evidence is direct and where you are still making an inference. That distinction is one of the most transferable troubleshooting skills in the course.