You do not get every artifact at once
Real troubleshooting is sequential. Each piece of evidence should change what you ask next. The goal of this lab is not to guess the cause from the first symptom. It is to choose the next observation that creates the largest useful split between competing hypotheses, then use that evidence to narrow the fault domain.
The best next test is the one that makes the hypotheses disagree
If two hypotheses both predict that the default gateway will answer ping, repeating that ping tells you almost nothing. A stronger test asks a question where the expected results diverge.
Weak test
Repeat a successful gateway ping when both hypotheses expect it to succeed.
Better test
Query the intended DNS resolver when the competing theories are DNS versus routing.
Best habit
Write the predicted result for each hypothesis before running the command.
A strong networking decision depends on more than recognizing a possible cause. Students also need to notice successful tests, respect the limits of the evidence, and avoid making changes before identifying the likely failure boundary. For additional practice, try our AP Networking Wrong Answer Detective. Its interactive scenarios explain why plausible answers fail and teach students how to recognize the reasoning mistakes that can cost them points on scenario-based questions.
New clients fail while existing clients still work
Initial symptom: Existing VLAN 70 devices remain online, but newly arriving devices self-assign APIPA addresses.
Existing clients continuing to communicate weakens the idea of a total access-switch failure. The highest-information next test is DHCP scope utilization combined with evidence that requests reach the server.
Decision: the scope is exhausted. Reclaim or expand capacity according to the address plan; do not reboot healthy access infrastructure.
Existing leases are a built-in control
A complete VLAN or switch outage should affect existing clients too. Existing devices continuing to pass traffic tells you that the Layer 2 path is working for at least some endpoints. New clients failing at lease acquisition moves DHCP allocation state much higher on the list.
Remote IP works, but an internal hostname fails
Evidence: the gateway responds. Remote numeric IP 10.90.5.20 responds. Querying app.campus.example against 8.8.8.8 returns NXDOMAIN.
The numeric IP test already proves useful Layer 3 reachability. Query the intended enterprise resolver.
Decision: correct the client or DHCP DNS setting. Do not create a public record merely because a public resolver lacks a private zone.
NXDOMAIN is meaningful only in the context of the resolver that produced it
A public resolver returning NXDOMAIN for a private enterprise hostname may be behaving correctly. The question is whether the client is asking the resolver that is authoritative—or at least intended—for that namespace.
One VLAN cannot reach a shared server
Evidence: VLAN 10 and VLAN 20 reach 172.16.50.10:443. VLAN 30 reaches its gateway but cannot reach the server.
The server itself is already proven available to other sources. Compare routing and firewall policy specifically for VLAN 30.
Decision: VLAN 30 has no matching allow before the deny. Add a narrow allow only if the requirement says VLAN 30 should have access.
Working source VLANs eliminate several broad hypotheses
If VLANs 10 and 20 reach the same server on the same port, the server listener, much of the routing path, and the destination itself are proven to a useful degree. The failing source network becomes the strongest differentiator.
Wi-Fi is slow while wired is fast on the same laptop and server
Evidence: Ethernet reaches about 900 Mbps with 2 ms local latency. Wi-Fi reaches 45 Mbps with latency varying from 8 to 160 ms. RSSI is strong.
Strong signal rules out only one class of wireless problem. It does not rule out contention, retries, interference, or excessive channel utilization.
Decision: the RF channel is heavily contended. Improve channel/capacity design. Upgrading the Internet circuit would not address this controlled local comparison.
The wired comparison isolates the access medium
Using the same laptop and same local server removes several variables. The endpoint hardware, application, destination, and upstream server path are held constant while the access medium changes.
A forward route exists, but replies never return
Evidence: Router A has a route to 10.80.0.0/16 through Router B. A capture at server 10.80.4.20 sees requests from 10.20.1.15, but the client never receives replies.
The packet reaching the server proves the forward path works to the destination. Inspect the server gateway and Router B's route back to the source.
Decision: replies follow the default toward the ISP. Add or advertise the correct internal return route, then verify bidirectional flow.
Seeing the request at the destination is a powerful checkpoint
Once a packet capture confirms that requests reach the server, do not keep troubleshooting the client's local cable or the forward route as if they were unproven. The evidence has moved the fault boundary.
High latency appears only during backup traffic
Evidence: remote latency is normal most of the day. During a scheduled backup, WAN utilization reaches 98 percent, output drops increase, and remote RTT rises sharply while the local gateway remains stable.
Decision: shared upstream congestion is strongly supported. The time correlation and stable local first hop weaken local LAN theories.
CRC errors rise while utilization stays modest
Evidence: users report intermittent file-transfer errors. The interface averages 24 percent utilization, but CRC/FCS errors increase quickly.
Low utilization weakens congestion. CRC growth strongly supports cabling, transceiver, interface, or negotiation trouble.
VLAN 30 fails while VLANs 10 and 20 cross the same trunk
The shared uplink is already carrying useful traffic, so replacing the cable is a weak first move. Inspect VLAN 30 allowance, tagging, existence, endpoint membership, SVI state, and policy.
Decision: the VLAN is not carried across the trunk. Add it according to the design, then verify same-VLAN reachability and any required routed paths.
After identifying a useful test, check whether your interpretation follows from the result. The Wrong Answer Detective reveals the most common ways students mistake plausible explanations for demonstrated causes.
Write the outcomes before running the next command
| Hypothesis | Test | Predicted result |
|---|---|---|
| DNS problem | Ping remote numeric IP | Works |
| Routing problem | Ping remote numeric IP | Fails |
| Scope exhaustion | Check free leases | Near/at zero |
| Access switch down | Existing client traffic | Also fails |
| Return route missing | Capture at server | Request arrives, reply path fails |
Swipe horizontally to see the prediction table.
Use each artifact only for the claim it can actually support
| Artifact | Useful proof | Still unproven |
|---|---|---|
| DHCP scope stats | Lease capacity state | End-to-end application access |
| DNS query | Resolver answer | TCP service availability |
| Firewall log | Policy decision | Server listener state |
| Route table | Path selection | Return route and policy |
| Wi-Fi retries | Wireless quality issue | ISP capacity |
Swipe horizontally to see the artifact boundaries.
Do not keep a theory alive after the evidence contradicts it
If a remote numeric IP is reachable, a total routing failure is too broad. If other VLANs cross the same trunk, a physically dead trunk is contradicted. If the server capture sees the request, the client's local path worked far enough to deliver it.
One change should answer one question
Changing DNS, gateway, firewall rules, and VLAN membership all at once may restore connectivity, but it destroys the evidence needed to know which change mattered. Make the narrowest supported correction, then re-test the original failure.
After the change: repeat the same measurements.
A repair is complete only when the mechanism and the original task both pass
Mechanism
The corrected configuration or state now matches the intended design.
User task
The original service or workflow now succeeds.
Control
Unrelated or prohibited behavior remains correct.
Use a negative control when policy or segmentation is involved
Testing only the allowed flow could miss an overly broad rule.
Record the decision path, not just the final answer
| Field | What to write |
|---|---|
| Initial symptom | Exact observed failure |
| Known-good | Successful checkpoints |
| Hypotheses | Two or three plausible mechanisms |
| Predicted outcomes | What each hypothesis expects |
| Chosen test | Why it has high information gain |
| Evidence | Actual result |
| Decision | Narrow supported conclusion |
| Verification | Mechanism + task + control |
Swipe horizontally to see the evidence-log format.
Choose the next test when three hypotheses remain
The best next test is not another ping. Query the intended DNS resolver and test TCP/443 separately. If DNS returns the correct address but TCP/443 fails, inspect the firewall and listener. If firewall logs show an allow but the server has no listener, the application becomes the first failed dependency.
This is the core lab skill: each new artifact should remove a branch.
Rank possible next tests by how much uncertainty they remove
When several tests are available, ask which one can eliminate the largest number of remaining explanations. A generic ping often has low value because many different failure states can still produce the same result. A targeted firewall log, route lookup for the exact destination, DHCP free-lease count, or resolver-specific DNS query can be far more discriminating.
| Candidate test | Information value | Why |
|---|---|---|
| Repeat gateway ping | Low | Many hypotheses already predict success |
| Check DHCP free leases | High | Directly separates exhaustion from path failure |
| Query intended DNS resolver | High | Separates resolver choice from routing |
| Inspect firewall hit counter | High | Shows which policy actually matched |
| Check route for exact destination | High | Tests path selection rather than generic reachability |
Swipe horizontally to see the decision-scoring table.
A successful test can narrow the problem without proving the whole system
Successful gateway ping proves a useful local checkpoint, but it does not prove DNS, remote routing, firewall policy, application listeners, or return-path state. A successful DNS query proves name resolution, but not TCP/443. A matching route proves path selection, but not that the next hop or reverse path works.
Write two or three hypotheses before choosing the next command
This keeps troubleshooting from becoming command roulette. For each hypothesis, write what you expect the next test to show if that hypothesis is true.
The most useful first test is the one that splits those predictions cleanly.
Two independent artifacts can make a conclusion much stronger
One artifact can be ambiguous. Two independent artifacts that point to the same mechanism are much stronger. For example, a firewall deny log plus a matching counter increment is stronger than either alone. A DHCP scope showing zero free leases plus new clients receiving APIPA is stronger than the APIPA symptom alone. A server capture showing incoming requests plus a missing return route strongly supports a reverse-path problem.
DHCP
APIPA + zero free leases.
Before choosing what evidence to collect next, make sure you are not asking an existing artifact to prove more than it can. A technically correct observation can still lead to a bad diagnosis when its limits are ignored. The companion lesson on network evidence that students commonly misdiagnose introduces the Evidence Ceiling method for deciding exactly what ping, traceroute, ARP, DNS, DHCP, routing, firewall, wireless, and performance evidence can—and cannot—justify.
Firewall
Deny log + rule counter.
Routing
Server sees request + reverse route absent.
Sometimes the best next action is another observation, not a configuration edit
If evidence is still compatible with several mechanisms, editing the network can destroy the very state you need to diagnose. Before changing a trunk, confirm the failing VLAN is absent. Before editing DNS, query the intended resolver. Before adding a firewall allow, confirm the rule path and requirement. Before changing routes, prove which route the packet currently selects.
Follow one case from vague symptom to defensible decision
This is the full evidence-lab process: start broad, preserve controls, choose a discriminating test, make one supported change, then verify the mechanism and the original user task.
24 Network Evidence Decision Lab digital flashcards
Practice high-information testing, hypothesis elimination, DHCP, DNS, VLANs, firewall logic, wireless controls, routing, return paths, performance evidence, artifact boundaries, change discipline, and verification.