Memory hook: Define the symptom; test one layer; verify the whole path.
Must remember
Start by identifying scope, symptoms, recent changes and what still works. Establish a plausible theory, test it, plan a low-impact fix, implement under the change process, verify full functionality and document cause/results. Escalate when the evidence or authority requires it.
| Symptom | Useful next check |
|---|---|
| No link | Cable/optic, administrative state, speed and power. |
| Increasing CRC errors | Physical quality, interference, optic/cable mismatch. |
| Link up, no usable address | VLAN and DHCP/relay/pool state. |
| Local works, remote fails | Prefix, gateway, route and ACL. |
| IP works, name fails | Resolver settings, DNS records and cache. |
| Small traffic works, large transfers stall | MTU/path-MTU and filtered ICMP. |
| Wireless intermittent | Channel contention, roaming, SNR and retries. |
ipconfig/ip inspect host configuration; ping checks selected reachability; traceroute/tracert expose responding hops; nslookup/dig query DNS; arp/ip neigh show neighbor bindings; netstat/ss show sockets; tcpdump or Wireshark inspect packets. Command availability differs by OS. A blocked ICMP response or a router deprioritizing probes does not necessarily mean the application path is broken.
Use cable testers for continuity/wiremap, toner/probe tools for cable identification, optical meters/OTDR for suitable fiber diagnosis and Wi-Fi analyzers for channel/radio evidence. Choose the instrument for the suspected fault; a speed test does not identify every wiring defect.
Inspect both directions. A request can leave successfully while the reply lacks a route, session state or policy permission. Duplicate addresses, wrong masks, exhausted DHCP pools, native-VLAN mismatches and stale DNS can appear intermittent.
Finish by testing the actual user service from the intended source, not just the nearest gateway. Record the fixed cause and update diagrams/baselines when the intended design changed.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Only one user fails | Compare that client/port/configuration with a working peer. |
| Everything fails after a change | Correlate the changed dependency and use the approved rollback if warranted. |
| Ping succeeds but web request fails | Test DNS, transport port, TLS and application behavior. |
Traps
- Traceroute timeouts can reflect filtering rather than a failed forwarding hop.
- Changing several variables at once destroys diagnostic clarity.
Active recall
1. Why establish scope first?
It narrows common dependencies and avoids testing unrelated components.
2. What does IP success but DNS failure suggest?
A name-resolution issue rather than total network loss.
3. Why check the return path?
Successful outbound forwarding does not guarantee replies can return.
4. What does a CRC counter suggest?
Corrupted frames, often from physical/link problems requiring further inspection.
5. What is the final verification?
The intended end-to-end service works and no unacceptable side effects remain.