A troubleshooting flowchart should answer one question: what is the first dependency not yet proven?
A useful flowchart is not a memorized order of commands. It is a sequence of evidence gates. Each successful gate preserves a part of the path and moves the unresolved question forward. Each failed gate stops the upward search and tells you which mechanism family deserves the next discriminating artifact.
After choosing a branch, use AP Networking Troubleshooting Methods and Documentation Practice Test to check the evidence behind that choice. The harder scenarios include clock uncertainty, changed workload, multiple simultaneous faults and sample coverage that can conceal a short outage.
Evidence-first flow
Scope → Attachment → Intended IP State → Gateway → Remote Numeric IP → DNS → Exact Transport/Service → Application → Targeted Change → Requirement-Matched Verification.
This matters because the same user phrase—“the network is down”—can describe a disabled switch port, failed DHCP, wrong VLAN, missing route, DNS failure, blocked TCP port, stopped server process, or application-layer error. The symptom begins the investigation; the first failed dependency localizes it.
Walk the gates in dependency order, but skip gates already proven by evidence
Define scope and the exact failed requirement
One endpoint, one VLAN, one site, one service, or everyone? Record what the user is trying to do and when it fails.
Is usable attachment established?
For Ethernet, inspect link/admin state and relevant switch evidence. For Wi-Fi, distinguish SSID visibility, association, and authentication.
Does the endpoint have the intended IP configuration?
Compare address, prefix/mask, gateway, DNS, and—when relevant—the expected VLAN or address source. “Has an IP” is not enough.
Can the endpoint reach the intended default gateway?
This gate tests the local IP/L2 path more directly than a public Internet test.
Can a remote numeric IP be reached?
A numeric destination avoids depending on DNS. Choose a target appropriate to the requirement; do not assume every host answers ICMP.
Does name resolution return the intended result?
Inspect configured resolver, query status, and returned record—not merely whether a browser eventually fails.
Does the required transport/service flow succeed?
Test the exact destination, protocol, and port. ICMP success cannot prove TCP/443 is listening or permitted.
Does the application complete the user's task?
If lower dependencies work, inspect application-specific state, authentication, certificates, server response, or content/service logic.
The same failed test means something different when one client fails versus an entire population
A gateway failure on one laptop while a peer on the same access network succeeds keeps attention close to the laptop, its configuration, its local policy, or its attachment. The same gateway failure across every endpoint behind one access switch makes a shared VLAN, uplink, switch, or gateway dependency more plausible.
| Failure scope | What it raises | Best comparison | What not to assume |
|---|---|---|---|
| One endpoint | Local config, interface, credential, host policy | Peer on same path | Site-wide outage |
| One VLAN/SSID | Mapping, DHCP, gateway, policy for that segment | Different segment on same infrastructure | Every switch/AP failed |
| One access switch | Switch/uplink/local trunk | Users on neighboring switch | DNS merely because apps fail |
| Multiple sites/services | Shared WAN, DNS, edge, cloud/service dependency | Local gateway and alternate service controls | Single endpoint defect |
Swipe horizontally to see the full table.
No link or association: do not troubleshoot services that cannot yet receive traffic
For wired Ethernet, distinguish physical link from administrative state. A dark link can reflect cable/path, transceiver, disabled interface, or peer-side state. A link light alone still does not prove correct VLAN placement or IP configuration. For wireless, SSID visibility is discovery evidence; association and authentication are separate transitions.
Link works but addressing is wrong: compare actual state with design intent
An APIPA address such as 169.254.x.x is useful evidence when automatic IPv4 configuration was expected, but it does not identify the exact DHCP failure. The client may be in the wrong VLAN, the DHCP path may be broken, the scope may be exhausted, or a local client issue may prevent acquisition. Likewise, a syntactically valid address can still be wrong for the intended network.
A healthy peer on the same VLAN receiving a new lease weakens a broad server-outage hypothesis. Multiple clients failing after a scope reaches zero available leases supports a different mechanism. The flowchart tells you where to look; the next artifact tells you which mechanism inside that branch is actually supported.
Expected IP but gateway failure: local forwarding is the first unresolved boundary
If address, prefix, and gateway match design intent but the gateway cannot be reached, testing public DNS moves too far downstream. Check whether the destination is considered local or remote, whether ARP/neighbor resolution succeeds, whether the switch learns the endpoint where expected, whether the VLAN is correct end to end, and whether a peer in the same segment reaches the gateway.
Gateway works but remote numeric IP fails: move beyond the local subnet
Gateway success preserves a large part of the local path: attachment, usable IP state, and enough local forwarding to reach the router interface. The next unresolved dependency can include route selection, upstream links, firewall policy, NAT where applicable, WAN state, or the remote path.
Use Routing in AP Networking when route choice is the question and Firewall Rules Explained when the exact flow may be filtered. A traceroute can suggest where responses stop, but silence at one hop does not automatically prove that hop drops the final traffic; devices can treat diagnostic probes differently.
Remote numeric IP succeeds but hostname fails: DNS becomes the high-information branch
Separate transport of IP packets from translation of names. Inspect which resolver the endpoint is configured to use, whether a query reaches it, the response status, and the returned record. A timeout, NXDOMAIN response, and wrong address are different signatures.
| DNS evidence | What it supports | What remains unknown |
|---|---|---|
| Resolver timeout | No usable response from selected resolver during test | Why: path, resolver, policy, client state |
| NXDOMAIN | Resolver says queried name does not exist in its view | Whether name was typed correctly or record should exist |
| Expected A/AAAA answer | Name resolution produced intended record | Whether transport/application succeeds |
| Wrong/stale address | Resolution works but returns unintended target | Source of stale/wrong data |
Swipe horizontally to see the full table.
The deeper separator is in Can Ping IP but Not Domain Name.
DNS works but the application still fails: test the exact protocol, destination, and port
A server can answer ICMP and still have no process listening on TCP/443. A firewall can allow ICMP while denying TCP/443. DNS can return the correct address while the service is stopped. That is why “ping works” is not equivalent to “the application path works.”
Use Port Blocked Troubleshooting to practice exact-flow evidence.
Choose the command after defining the unknown—not before
| Unknown | Possible evidence source | Useful result | Limit |
|---|---|---|---|
| Actual endpoint IP state | ipconfig / ifconfig / ip | Address, mask/prefix, gateway, DNS | Configuration does not prove reachability |
| Local neighbor resolution | arp / ip neigh | Neighbor mapping/state | Does not prove remote routing |
| Route decision/path | route/ip route, traceroute | Selected route or observed hop responses | Traceroute silence is not automatic fault proof |
| Name resolution | nslookup/dig | Resolver response and record | Does not prove application service |
| Listening service | netstat/ss | Local socket/listener state | Listener does not prove firewall permits remote flow |
Swipe horizontally to see the full table.
See Network Command-Line Tools and Network CLI Output Practice for artifact-focused drills.
The flowchart is two-dimensional: where the path breaks and who shares the break
Dependency order alone is not enough. If ten users behind one switch lose their gateway simultaneously, the shared access/uplink path deserves attention before ten independent host failures. If one endpoint fails while a peer on the same VLAN and switch works, the shared infrastructure becomes less likely.
Change one fact and force the flowchart to take a different branch
Memorizing “APIPA means DHCP” is weaker than understanding what evidence would invalidate the branch. For each scenario, ask what single new fact would make your current next test less useful.
- APIPA, but the design intentionally uses link-local addressing → normal DHCP failure is no longer established.
- Gateway fails, but every peer also loses the gateway at the same timestamp → widen scope toward the shared path.
- Remote IP fails, but the chosen host intentionally blocks your probe → choose evidence tied to the required service instead of declaring routing failure.
- Hostname fails, but an explicit DNS query returns the expected record → move beyond DNS to the exact application flow.
- TCP/443 fails, but the server has no listener → repair service state before changing firewall policy.
Prefer artifacts that intersect the exact failed decision
A user symptom defines the requirement but usually has low specificity. A configuration snapshot narrows possibilities. A successful control can eliminate shared dependencies. A timestamped device log or socket state that matches the exact failed flow can be stronger still. Verification closes the chain.
| Evidence | Example | Diagnostic value |
|---|---|---|
| Symptom | “Portal will not open” | Defines failed task; mechanism broad |
| State | Expected IP/gateway/DNS present | Preserves configuration checkpoints |
| Control | Peer on same VLAN succeeds | Narrows population/shared-path hypotheses |
| Mechanism artifact | No TCP/443 listener or exact firewall deny | Intersects required transport decision |
| Verification | Original HTTPS task succeeds after narrow repair | Connects correction to requirement |
Swipe horizontally to see the full table.
When the network is healthy now, build a timeline for the next failure window
A snapshot taken after recovery can erase the most useful evidence. Record before/during/after timestamps for interface transitions, DHCP events, route changes, spanning-tree events, wireless retries, firewall logs, CPU/load, and service restarts. Correlate the artifact to the same endpoint, path, and user operation.
Correlation is not automatic proof of root cause, but a mechanism-relevant event aligned with the failure gives you a high-information next test.
A repair is not complete until the original requirement works and important controls remain intact
Verification should be predicted before the change. If a DHCP/VLAN correction is right, the client should acquire the intended address through the normal process—not merely work after a temporary static address. If a firewall correction is right, the required flow should succeed while a prohibited control remains denied. If a routing correction is right, the intended prefix should use the expected path and unrelated routes should remain stable.
| Repair branch | Mechanism verification | User verification | Control |
|---|---|---|---|
| Attachment | Expected link/association state | Endpoint reaches next dependency | Neighboring ports/SSIDs unchanged |
| DHCP/VLAN | Normal lease in intended subnet | Required service reachable | Segmentation preserved |
| Routing | Correct route/path evidence | Remote requirement succeeds | Other prefixes stable |
| DNS | Expected query answer | Name-based application succeeds | Numeric-IP path remains healthy |
| Firewall | Required tuple allowed | Exact application succeeds | Unauthorized tuple remains denied |
Swipe horizontally to see the full table.
Turn the flowchart into a concise evidence argument
This structure is stronger than naming a command alone because it states the observation, preserves known-good evidence, identifies the boundary, chooses a discriminating artifact, and defines verification.
Walk one failure from vague symptom to a narrow, testable mechanism
A student says, “The learning portal is down.” First, scope it: only one classroom is affected. Link is up. Endpoints have the expected address configuration. Gateway reachability succeeds. A remote numeric IP succeeds. DNS returns the expected portal address. TCP/443 to that address fails. At this point, the flowchart has eliminated large parts of the path without claiming they are perfect in every possible way.
Now compare service and policy evidence. The server shows a TCP/443 listener. A firewall log generated during reproduction records a deny matching the classroom subnet, portal address, TCP, and destination port 443. The exact-flow intersection makes policy a justified repair boundary. After the narrow rule correction, HTTPS succeeds from the affected classroom. A separate prohibited test remains denied. The incident is now an evidence chain rather than a sequence of guesses.
24 interactive network troubleshooting flowchart flashcards
These cards test evidence boundaries and next-test selection. Before revealing an answer, state what has already succeeded and one result that would weaken your hypothesis.