A systematic approach to diagnosing and resolving network problems — from physical cables to application layers.
Effective troubleshooting follows a structured approach rather than randomly trying fixes. The CompTIA vendor-neutral model adapted for networking:
When starting fresh, always check Layer 1 (Physical) first, then work upward. Statistically, ~60% of network issues are Layer 1 or Layer 2. A loose cable will never be found by checking firewall rules.
Master these tools and you can diagnose 90% of everyday network issues.
-v for verbose output to see HTTP headers and TLS handshake details. Excellent for web service debugging.ipconfig /all. Linux: ip addr show.ping -M do -s 1472 <target>. On macOS: tracepath.Reply from... = connection is working. Watch the time value — under 50ms is excellent (LAN), 50-150ms good (WAN), over 200ms sluggish. Request timed out = packet dropped somewhere (firewall, unreachable, or overloaded). Destination host unreachable = local routing problem (wrong gateway or no route). TTL expired = seen in traceroute when a router drops packets with exhausted TTL.
Asterisks (*) at a hop mean the router didn't respond (often ICMP is filtered). This doesn't necessarily mean the path is broken — the next hop may still receive traffic. A consistent asterisk pattern throughout usually indicates a transparent router. Look for latency spikes at specific hops — that's where the problem likely lives.
Wireshark captures packets as they pass through a network interface, letting you inspect every byte of traffic. It's the ultimate diagnostic tool when other commands fall short.
| Concept | Description |
|---|---|
| Capture Filter | BPF syntax applied BEFORE capturing (e.g., host 192.168.1.1). Reduces disk usage by filtering at the driver level. |
| Display Filter | Applied AFTER capture to view specific traffic (e.g., tcp.port == 80). Doesn't discard data, just hides it. |
| Three-pane view | Top: packet list. Middle: packet details (protocol tree). Bottom: raw packet bytes (hex + ASCII). |
| Color coding | Green=normal, Red=error/tls warning, Yellow=warning, Blue=selected. Customizable. |
| Follow Stream | Right-click a packet → Follow → TCP Stream to reconstruct the entire conversation in readable format. |
ip.addr == 192.168.1.1 — All traffic to/from an IPtcp.port == 80 — All HTTP trafficdns.qr == 0 — DNS queries only (not responses)tcp.flags.syn == 1 && tcp.flags.ack == 0 — TCP three-way handshake initiationtcp.analysis.retransmission — Retransmitted packetsicmp — All ICMP traffictls.handshake.type == 1 — TLS Client Helloeth.dst == ff:ff:ff:ff:ff:ff — Broadcast traffictelnet — Unencrypted login attempts (security hunting)http.requesttls — observe the encrypted handshake instead.dns filter and examine a DNS query/response pair. Note the difference between UDP (query) and potentially TCP (if response is large).Physical media failures account for a significant portion of network incidents. Cable testers range from $20 continuity testers to $2,000+ certification instruments.
| Tool | What It Tests | Cost Range | Use Case |
|---|---|---|---|
| LED Continuity Tester | Basic wire map (pin 1 to pin 1, etc.), open/short detection | $10–$50 | Quick field verification of patch cables |
| TONER & probe kit | Trace cables through walls/closets, identify cable ends | $20–$100 | Cable identification in patch panels |
| Certificate Cable Tester | Wire map, length, attenuation, crosstalk, return loss, near-end crosstalk (NEXT) | $500–$2,000+ | Compliance testing per TIA/EIA standards |
| OTDR (Optical Time Domain Reflectometer) | Fiber loss, break location, splice points, connector loss | $2,000–$15,000+ | Fiber optic installation and troubleshooting |
| Multimeter | Voltage on PoE ports, continuity, resistance | $20–$200 | Verifying PoE power delivery, basic electrical checks |
T568A: White-Green, Green, White-Orange, Blue, White-Blue, Orange, White-Brown, Brown
T568B: White-Orange, Orange, White-Green, Blue, White-Blue, Green, White-Brown, Brown
Patch cables should use the same standard on both ends (T568B-T568B). Crossover cables use different standards on each end (rarely needed with modern auto-MDI/X NICs).
Wi-Fi issues are among the most frustrating to diagnose because symptoms are often intermittent and environment-dependent.
| Issue | Likely Causes | Diagnostics | Fixes |
|---|---|---|---|
| Poor signal strength | Distance, obstacles, interference | wifi analyzer apps, iwconfig, netsh wlan show networks | Reposition AP, add repeater, reduce obstacles |
| Channel congestion | Too many APs on same channel, neighboring networks | Spectrum analyzer, WiFi scanner app | Switch to less congested channel (1, 6, 11 for 2.4GHz) |
| Slow throughput | Wrong security mode, old client, co-channel interference | Speed tests, ethtool, check negotiated rate | Upgrade to WPA3, disable legacy 802.11b/g, increase bandwidth |
| Auth failures | Wrong passphrase, RADIUS issues, certificate problems | Verify credentials, check RADIUS server, renew certificates | |
| Roaming issues | Client won't deauth from old AP, signal threshold misconfigured | Check roaming thresholds, test with client probe requests | Adjust RSSI kickback threshold, enable 802.11r/k/v fast transition |
| Intermittent drops | Interference from microwaves, Bluetooth, bad cabling to AP | Spectrum scan, cable tester on backhaul | Change channels, upgrade cabling, move AP away from sources |
2.4 GHz: Better range and penetration through walls, but crowded (microwaves, Bluetooth, neighbors) and slower max speeds. Use for IoT devices and distant clients.
5 GHz: Faster speeds, more non-overlapping channels, less interference — but shorter range and poorer wall penetration. Use for high-bandwidth tasks (video, large files).
| Symptom | Probable Cause | Diagnostic Steps | Resolution |
|---|---|---|---|
| No internet, LAN works | Default gateway or DNS failure | ipconfig /all check gateway and DNS; ping 8.8.8.8 (works) vs ping google.com (fails) |
Renew DHCP lease; verify ISP uplink; check DNS settings |
| 169.254.x.x address | DHCP failure — APIPA assigned | ipconfig /release && ipconfig /renew; check DHCP server status and scope availability |
Restart DHCP server; check scope exhaustion; verify switch port isn't blocking DHCP (port 67/68) |
| Intermittent connectivity | Cable fault, duplex mismatch, interference | show interface for errors/drops; cable tester; check link lights |
Replace cable; set correct duplex/speed (prefer auto-negotiate); move away from interference source |
| Can ping IP but not hostname | DNS resolution failure | nslookup / dig; check /etc/resolv.conf or DNS server config |
Configure correct DNS server; flush DNS cache; check DNS forwarder on gateway |
| Limited/no connectivity (Windows) | IP conflict or incorrect subnet mask | arp -a check duplicate MAC; ipconfig verify mask matches network |
Assign static IP outside DHCP range; correct subnet mask; enable DHCP snooping |
| Can't reach remote subnet | Missing route, ACL blocking, NAT misconfiguration | tracert to find where packets drop; show ip route on router |
Add missing route; adjust ACL; verify NAT translation table entries |
| High latency on local network | Switch loop, duplex mismatch, overloaded link | show spanning-tree; show interfaces counters for collisions/crc errors |
Fix STP topology; ensure matched duplex settings; aggregate links with LACP |
| SSL/TLS certificate errors | Expired cert, wrong hostname, untrusted CA | Browser error details; openssl s_client -connect host:443 |
Renew certificate; fix hostname matching; install missing CA bundle |
Symptom: Every weekday at approximately 9:00 AM, the entire office loses internet access for 5–10 minutes. Internal LAN continues working fine.
Investigation:
Root Cause: Aging coaxial drop cable inside the building, weakened by years of elevator vibration, creating intermittent signal degradation when the motor cycles on.
Resolution: Replaced the coaxial cable with shielded CAT6 runs to the optical converter. Added a fiber uplink as backup path. Outages eliminated entirely.
Lesson: Pattern-based issues require correlating timing with environmental factors. Layer 1 problems can manifest as seemingly higher-layer symptoms.
Symptom: Several departments report they cannot print to a network printer, though everyone can ping it. The print queue appears full but jobs never process.
Investigation:
storm-control broadcast level 10% and the printer was generating broadcast storms due to a misconfigured protocolRoot Cause: Storm control on the switch port was dropping excessive broadcast traffic during surge periods, preventing some clients' ARP requests from reaching the printer.
Resolution: Adjusted storm-control threshold to 30%, replaced the printer's firmware, and moved the printer to a dedicated access vlan with appropriate QoS priority for control traffic.
Lesson: When connectivity seems inconsistent (some can reach, others can't), consider Layer 2 broadcast behaviors and switch configurations.
Symptom: Users report browsers showing security warnings on multiple internal sites after a routine maintenance window. Some applications fail to authenticate.
Investigation:
openssl s_client -showcerts -connect site:443 — saw the intermediate certificate was missing from the chainRoot Cause: Maintenance automation removed the intermediate certificate from Nginx's ssl_certificate directive, keeping only the leaf cert. Browsers that cached the full chain before still worked; fresh connections failed.
Resolution: Restored the full certificate chain (leaf + intermediates) in the correct order. Added a pre-deployment validation step that runs openssl s_client -showcerts against each endpoint.
Lesson: SSL certificate chain issues often affect only some users (those without cached chains). Always validate the full certificate chain, not just individual certs.
Good documentation turns individual heroics into organizational capability. An incident you solve today shouldn't become someone else's emergency next month.
| Element | What to Include | Why It Matters |
|---|---|---|
| Incident Summary | Date/time, affected systems, severity, duration | Quick reference for pattern analysis and reporting |
| Symptoms Observed | Exact error messages, user descriptions, affected scope | Enables rapid symptom-to-cause matching for future incidents |
| Diagnostic Steps Taken | Commands run, outputs captured, hypotheses tested and ruled out | Prevents re-investigation and documents what was tried |
| Root Cause | Specific technical cause with evidence (logs, captures, configs) | Addresses the actual problem, not just the symptom |
| Resolution | Step-by-step fix applied, verification performed | Repeatable recovery if the issue recurs |
| Preventive Actions | Configuration changes, monitoring alerts, process updates | Stops the same issue from happening again |
Trigger: User reports "can't get internet" or "slow network"
Step 1: Determine scope — one device or multiple? One floor or entire building?
Step 2: Physical check — link lights on NIC and switch port? Correct cable?
Step 3: IP config — ipconfig /all or ip addr. Is there an APIPA (169.254.x.x)?
Step 4: Local reachability — ping 127.0.0.1 (loopback), then ping <own_IP>, then ping <gateway>
Step 5: External reachability — ping 8.8.8.8. If this works, it's a DNS issue.
Step 6: DNS check — nslookup google.com. If it fails, check DNS server config.
Step 7: Trace the path — traceroute 8.8.8.8 to find where packets are dropping.
Step 8: If all above passes but app still fails, check application-specific ports with telnet <host> <port> or nc -zv <host> <port>.
ipconfig /all (Windows) or ip addr (Linux). Record your IP, subnet mask, gateway, and DNS servers.traceroute 8.8.8.8 (or tracert on Windows). How many hops to reach Google's DNS? Which hops show highest latency?netstat -an | grep LISTEN (Linux) or netstat -an (Windows) to identify all listening services on your machine.nc -zv google.com 443. Does it succeed?nslookup and dig. Compare the output detail levels.netsh wlan show networks mode=bssid (Windows) or iw dev wlan0 scan (Linux) to discover nearby networks.http, then tls, then dns, then icmp.tcp.analysis.retransmission. If none appear, try downloading a large file and re-checking.