A symptom is a boundary clue—not a diagnosis
The same user complaint can be produced by different mechanisms, while one mechanism can produce several symptoms downstream. This database is designed to prevent “symptom matching” from turning into guessing. Start with the observation, preserve every known-good checkpoint, define the failure scope, and choose the next artifact whose possible outcomes separate the remaining explanations.
The database uses Symptom → Scope → Known-Good Checkpoint → Candidate Boundary → Discriminating Evidence → Falsifier → Next Test → Verification. The “falsifier” matters: a strong hypothesis predicts evidence that could prove it wrong.
Fast symptom-to-evidence matrix
Use this table to decide where the uncertainty begins. The “do not overclaim” column is as important as the likely boundary.
| Observed signature | Candidate boundary | Best next evidence | Useful falsifier/control | Do not overclaim |
|---|---|---|---|---|
| No Ethernet link on one endpoint | NIC/cable/termination/switch port | Both-end interface state; controlled cable/port swap | Same device links on known-good path | No link does not identify which physical component failed. |
| 169.254.x.x IPv4 address | Normal DHCP acquisition/path | VLAN, DHCP exchange/log, scope/relay, peer lease | Static known-good config reaches gateway only as controlled test | APIPA does not identify the DHCP cause. |
| Expected IP but gateway unreachable | Local subnet/ARP/VLAN/gateway | ARP/neighbor state, peer gateway test, switch/VLAN evidence | Peer in same VLAN reaches gateway | Do not jump to DNS or WAN. |
| Gateway works; remote numeric IP fails | Routing/edge/firewall/NAT/WAN | Route, hop progress, edge state/logs | Another source through same edge succeeds | Gateway success proves only the tested first-hop path. |
| Remote numeric works; hostname fails | DNS resolver/query/record path | Resolver config and query response | Query intended resolver directly | Do not change the default route without contrary evidence. |
| One VLAN fails across a trunk; another works | VLAN-specific Layer 2 path/config | VLAN existence, allowed list, tagging, endpoints | Same VLAN works across alternate path | Working VLAN weakens total trunk failure. |
| Many MACs move rapidly + broadcasts spike | Layer 2 loop candidate | MAC move timeline, broadcast rate, STP/topology | Moves isolated to one identity without broad broadcast rise | One moving MAC is not a broadcast storm. |
| One IP alternates between MAC addresses | Duplicate IP/ownership candidate | ARP timeline + switch MAC location + DHCP/static inventory | Intentional HA/shared-IP design | A ping reply cannot identify the owner. |
| Correct IP/gateway; one TCP service times out | Transport/policy/listener/path | Exact-flow test, firewall log, listener, packet direction | Another port/service to same host succeeds | Ping does not prove the TCP service. |
| Latency rises only under load | Queueing/congestion candidate | Idle-vs-load latency, utilization, queue drops | Latency rises without utilization/queue correlation | High latency is not automatically low bandwidth. |
| One device slow; peers fast | Endpoint/access-path candidate | Same-workload peer, link errors, Wi-Fi, processes, VPN | Symptom follows jack/AP/path instead of device | One slow device does not prove the LAN is healthy everywhere. |
| Wi-Fi fails; wired control works | Wireless access/RF/auth/VLAN | BSSID, association/auth, RSSI/SNR, retries, VLAN/DHCP | Same client works wired through shared upstream | Do not blame WAN before testing the unique wireless path. |
| Wi-Fi associated; no IP lease | Post-association VLAN/DHCP path | Auth role/VLAN, DHCP exchange, relay/scope | Peer on same BSSID/VLAN leases normally | Association does not prove DHCP. |
| Strong RSSI but poor throughput | Airtime/interference/retries/capacity | SNR, retries, channel utilization, rate, control band | Clean wired/local-server control | Strong signal is not proof of clean airtime. |
| Route exists but destination unreachable | Route usability/next hop/return path/policy | Longest-prefix match, adjacency, hop progress, return route | Alternate prefix/path succeeds | Route presence does not prove forwarding. |
| Internal site fails; public Internet works | Private DNS/route/policy/proxy/service | Private resolution, exact route, TCP/TLS/app response | Working peer or another internal service | Public browsing does not prove private dependencies. |
Swipe horizontally to see the full database.
No link, flapping link, and error-growing link are three different signatures
Attachment never establishes
Compare NIC state, switch-port state and a known-good cable/port. Do not troubleshoot DNS while attachment is absent.
Attachment repeatedly changes state
Correlate timestamps at both ends with movement, power, port events and negotiation. A snapshot after recovery can hide the failure.
Link remains up but frames fail
Use counter deltas during reproduced traffic. Lifetime CRC/error totals without a time window are weaker evidence.
A controlled substitution is most useful when only one variable changes. If the same endpoint and cable work on another port, that does not prove the original switch port alone is defective; the original port may differ in VLAN, policy, patching or physical path. State exactly what the experiment isolated.
APIPA, wrong subnet, wrong mask, duplicate IP and wrong gateway should not collapse into “bad IP”
A 169.254 address means expected IPv4 configuration was not obtained; it does not distinguish DHCP scope exhaustion from a blocked relay path or wrong VLAN. An unexpected but valid-looking subnet can instead indicate wrong VLAN/scope. A wrong mask changes the host's local-versus-remote decision. A wrong gateway can leave local communication intact while remote networks fail. A duplicate IP can produce intermittent ownership changes rather than a clean outage.
Compare Duplicate IP Address Symptoms, Wrong Subnet Mask Symptoms, and Wrong Default Gateway Symptoms.
Use scope to separate one VLAN problem from a trunk-wide or loop-wide failure
If VLAN 20 fails across a trunk while VLAN 30 crosses the same physical trunk successfully, the working VLAN is a powerful control. It weakens a total physical-trunk failure and shifts attention to VLAN existence, tagging, allowed-VLAN state, access membership and VLAN-specific spanning-tree or policy state. It does not prove which of those mechanisms is wrong.
A loop signature is broader: repeated flooding can amplify broadcasts/unknown traffic, MAC locations may oscillate, utilization can rise and many clients may degrade together. One MAC moving between ports is insufficient by itself because mobility, virtualization, redundancy or duplicate identity can produce narrower movement.
For mechanism detail, use Network Loop and Broadcast Storm, MAC Address Table Explained, and VLAN Mismatch Symptoms.
“Route exists” is configuration evidence; forwarding progress is behavioral evidence
For an unreachable remote network, determine the source IP/prefix, the host's local-or-remote decision, the exact route selected for the destination, the next hop, forwarding progress, destination-network arrival, return route and policy/state. Longest-prefix matching matters: a more-specific stale route can defeat a healthy default route.
Traceroute or hop evidence should be treated carefully. A responding hop proves progress to that observation point; asterisks do not automatically identify the broken router because devices can deprioritize or filter diagnostic responses while forwarding transit traffic. Pair path evidence with route/adjacency and destination-specific controls.
Numeric success followed by name failure moves the boundary; it does not end the investigation
If a remote numeric destination works while the intended hostname fails, preserve the routed-IP checkpoint. Inspect the configured resolver, resolver reachability, query result and returned address. A timeout, NXDOMAIN and wrong answer are different signatures. If DNS returns the intended address, move forward again to the exact transport/application flow.
Likewise, ping success is not proof that TCP/443 is available. A TCP timeout, explicit refusal and successful establishment carry different evidence. Once TCP establishes, unresolved dependencies move toward TLS, proxy, HTTP or application state.
Use Can Ping IP but Not Domain Name and Port Blocked Troubleshooting for those branches.
Performance symptoms require a comparison condition, not just a slow result
“Slow” should be decomposed into latency, jitter, loss, throughput, transaction time or airtime behavior. If latency is normal while idle but rises sharply under offered load, queueing/congestion becomes a candidate. Correlate the same time window with interface utilization, queue occupancy/drops or competing traffic. A fast link speed does not prevent queueing at a slower downstream bottleneck.
If only one endpoint is slow, compare the same workload from a healthy peer under the same conditions. The bottleneck may follow the device, Ethernet negotiation/errors, Wi-Fi association, background upload, VPN/proxy path, CPU/disk/security inspection, or application—not the shared network.
Continue with Network Congestion Explained, High Jitter, or Network Performance.
Wi-Fi “connected” has multiple checkpoints after association
Wireless diagnosis benefits from a state chain: Visibility → BSSID/AP → Association → Authentication → Authorization/Role → RF/Airtime → VLAN → DHCP → Gateway → Remote IP → DNS → Application. An association icon proves only an early transition. A client can associate successfully yet fail enterprise authentication, receive the wrong role/VLAN, miss DHCP, or suffer high retry rates.
Strong RSSI is another common false positive. Signal strength does not measure noise, contention or retries. Compare SNR, channel utilization, retry behavior, data rate and a wired/local control. Conversely, weak RSSI with acceptable application behavior may not violate the actual requirement.
Use Wireless Networking, Wireless Authentication Failure, and Wi-Fi Channel Interference.
Six observations that tempt students to overdiagnose
“Ping works, so the server is fine.”
False. ICMP success does not establish the required TCP listener, TLS, HTTP or application.
“There is a route, so routing is fine.”
False. The route can point to an unusable next hop or lose the return path.
“Wi-Fi bars are strong, so RF is fine.”
False. Strong RSSI can coexist with interference, contention and retries.
“The link light is on, so Ethernet is fine.”
False. VLAN, errors, DHCP and all higher dependencies remain unresolved.
“One MAC moved, so there is a loop.”
False. A broad loop needs correlated topology/flooding/MAC evidence.
“169.254 means DHCP server down.”
False. It identifies failed normal address acquisition, not the precise mechanism.
Two independent artifacts are often stronger than one dramatic symptom
| Artifact pair | Stronger combined inference | Remaining uncertainty |
|---|---|---|
| ARP ownership alternates + MACs locate on two access ports | Two Layer 2 identities are claiming/reachable for one IP context | Accidental duplicate vs intentional shared-IP design |
| Latency rises under load + output queue drops rise same interval | Queueing at that interface is strongly correlated with symptom | Why offered load exceeds service rate |
| One VLAN fails + another VLAN crosses same trunk | Physical trunk can carry at least some traffic | Allowed/tagging/VLAN/STP specifics for failed VLAN |
| TCP SYN reaches server + no SYN-ACK leaves | Forward path reaches server observation point | Listener, host firewall, local server stack |
| Correct DNS answer + TCP/443 establishes | Name resolution and transport checkpoint succeed | TLS/HTTP/application/backend |
Swipe horizontally to see the full table.
Rates, deltas and timelines can reveal mechanisms hidden by snapshots
A single interface counter of 4,000 errors is hard to interpret without uptime and traffic volume. If errors rise by 300 during a 30-second reproduced transfer while a control interface remains flat, the delta is far more useful. The same applies to MAC moves, ARP ownership, channel utilization, DHCP failures, latency and packet loss.
Build a timeline for intermittent incidents: symptom begins, link state changes, lease renews, route changes, MAC moves, policy logs appear, service recovers. Correlation is not automatic causation, but synchronized events can identify the dependency whose state changed with the symptom.
Ask “what shares this dependency?” before blaming a component
| Scope | Dependencies that become more plausible | Control that reduces uncertainty |
|---|---|---|
| One endpoint, every destination | Endpoint config, NIC/access link, local policy, VPN/proxy | Healthy peer on same network |
| Many endpoints, one destination/service | Destination, service, policy, route specific to destination | Other destinations from same sources |
| One VLAN only | VLAN path, gateway/SVI, DHCP/relay, VLAN-specific policy | Another VLAN sharing physical infrastructure |
| One building/switch | Shared uplink, power, trunk, gateway path | Neighbor site/switch using same core services |
| Everyone, all destinations | Core/edge, shared DNS, WAN, widespread power/control-plane issue | Local-vs-remote and service-specific tests |
| Only under peak load | Capacity, queueing, airtime, resource exhaustion | Same path/workload off-peak |
APIPA across new clients, but old leases still communicate
Three newly connected clients in one VLAN receive 169.254 addresses. Existing clients with valid leases continue reaching the gateway and Internet. That scope weakens a total VLAN or gateway outage. DHCP scope data shows no free leases. After the approved scope correction, a fresh client receives the intended address, gateway and DNS values and completes the original application test.
The symptom did not prove “DHCP server down.” Existing leases and the scope artifact separated exhaustion from a total server failure.
One VLAN fails across a trunk while another VLAN remains healthy
Users in VLAN 20 lose connectivity across a switch-to-switch trunk; VLAN 30 users across the same physical link remain healthy. The failed VLAN exists at both ends, but trunk evidence shows VLAN 20 missing from the allowed set on one side. Restoring the approved VLAN allowance returns VLAN 20 traffic while VLAN 30 remains unaffected.
The working VLAN was a falsifier for “the trunk cable is dead.” It did not, by itself, identify the allowed-list error; configuration evidence did that.
High latency under load correlates with one constrained egress queue
Idle latency is normal. During a large upload, latency and application delay rise for multiple clients. At the same interval, the shared egress interface approaches its service rate and output queue drops increase. When the offered load ends, both queue evidence and latency recover.
This correlation supports queueing at a shared bottleneck far better than a generic “network is slow” diagnosis. Verification should repeat comparable load after the justified capacity/QoS correction rather than testing only at idle.
Strong Wi-Fi signal, poor performance, and rising retries
A client reports strong RSSI near the AP but poor throughput during a busy period. SNR is adequate, yet retry percentage and channel utilization rise sharply. A wired control through the same upstream network remains healthy. Moving the client to a cleaner approved channel/band plan reduces retries and restores the required workload.
Strong RSSI was not evidence of clean airtime. The wired control preserved the shared WAN path and moved the investigation toward the wireless-specific dependency.
Remote IP works, hostname fails, and the resolver times out
The client reaches its gateway and a remote numeric destination. The intended hostname fails. DNS queries to the configured resolver time out while a working peer uses a different managed resolver. Correcting the resolver configuration restores name resolution and the original application.
Because numeric routed traffic succeeded, changing Ethernet, VLAN or default gateway would have ignored the last known-good checkpoint.
One TCP port fails while the same host answers other services
The destination resolves correctly, routes successfully, and responds on an approved management service, but TCP/443 times out. A firewall log generated during the reproduction matches the exact source, destination and port to a deny rule. The approved narrow policy correction restores HTTPS; a prohibited comparison flow remains blocked.
This is an exact-flow diagnosis. Host reachability and one working service are controls against the claim that the destination is simply “down.”
Choose the next test by information gain, not habit
If two hypotheses predict the same outcome for a test, that test has little discriminating value. Suppose DNS failure and a dead Ethernet link are both being considered, but the client already reaches a remote numeric IP. Repeating ping adds little. Querying the configured resolver directly can separate resolver reachability from record behavior. Likewise, when deciding between endpoint failure and jack/path failure, a two-way controlled swap can be more informative than rebooting both devices.
Write from evidence boundary to mechanism—not from symptom to guess
Observation: “The client reaches its gateway and a remote numeric address but cannot resolve the required hostname.” Bounded inference: “The tested local and routed IP path works without DNS, so a broad physical-link or default-gateway failure is unlikely for this attempt.” Next evidence: “Inspect the configured resolver and issue the exact DNS query.” Mechanism: “If the query to the configured resolver times out while a working peer's intended resolver answers, resolver configuration/reachability explains the name-only failure.” Verification: “Resolve the original hostname and repeat the required application without changing unrelated routing.”
Match verification to the mechanism you actually changed
| Changed mechanism | Positive verification | Control/negative verification |
|---|---|---|
| Physical path | Expected link and workload remain stable under traffic | Error deltas stay normal; unaffected path remains healthy |
| DHCP | Fresh client obtains complete intended lease | Existing scopes/clients remain healthy |
| VLAN/trunk | Failed VLAN traverses intended path | Other VLANs remain correctly isolated/carried |
| Routing | Exact destination follows intended path both directions | Unrelated prefixes retain intended route |
| Firewall | Approved exact flow succeeds | Prohibited comparison flow remains denied |
| DNS | Exact name returns intended answer and service works | Other required names still resolve correctly |
| Performance | Original workload meets requirement under comparable load | Measure same metric, not a different easier test |
| Wireless | Required workload succeeds in target locations/conditions | Roaming/security/segmentation behavior remains correct |
24 network failure signature flashcards
These cards test the evidence boundary, falsifier and next discriminating artifact—not just vocabulary.