7 Network Troubleshooting

A systematic troubleshooting process

Network troubleshooting is a controlled process for finding and correcting the cause of a fault, not a sequence of guesses. A useful diagnosis narrows the fault to a layer, device, service, path, or policy while minimizing disruption. The troubleshooting methodology includes identifying the problem, testing likely causes, planning and implementing a fix or escalating, verifying the result, preventing recurrence where appropriate, and documenting throughout.

Identify, test, and resolve the fault

1. Identify the problem. Find out what the user was trying to do, what happened, when the issue began, and whether anything changed. Record the exact error and determine the scope: one user, device, location, service, or the whole network. Reproduce the issue if safe, and separate unrelated symptoms.

2. Establish a theory of probable cause. Question obvious possibilities and consider more than one cause. Use the OSI model to organize hypotheses: start at the physical layer and move upward (bottom-up), start with the application and move downward (top-down), or test a useful middle point and work in either direction (divide and conquer).

3. Test the theory. Choose a test that distinguishes between likely causes. Predict what successful and unsuccessful results would mean. If a test disproves the theory, form another theory or escalate; do not keep changing settings without evidence.

4. Plan the fix. Consider impact, authorization, maintenance windows, backups, and possible side effects. Prefer the smallest reversible change that addresses the confirmed cause.

5. Implement or escalate. Apply the approved change, or hand off the issue with the evidence gathered if it is outside your access or expertise.

6. Verify and prevent recurrence. Confirm that the original task works and check related functions. Where appropriate, add preventive measures such as correcting a configuration baseline, monitoring a link, or updating documentation.

7. Document throughout. Record symptoms, scope, tests, results, changes, verification, and lessons learned. Documentation supports future diagnosis and helps identify recurring faults.

Scope the fault and trace the path

Determine whether the issue affects one endpoint or many. One affected device suggests its adapter, configuration, cable, or client software. Multiple devices sharing a switch, VLAN, access point, site, or service point toward shared infrastructure or policy. Compare affected and unaffected users, locations, times, and applications.

Trace the intended traffic path: endpoint → access switch or wireless AP → VLAN and gateway → routing or firewall devices → destination service. Check each boundary in order. A network diagram showing devices along the path can help focus tests.

For a local-network failure, inspect link state, switch port, VLAN, and address resolution. For an off-subnet failure, check the IP address, subnet mask, default gateway, routing, and filtering. Ping can test basic reachability, but a failed ping alone does not prove that an application is unreachable because ICMP may be filtered. Test the relevant service and port as well.

Check connectivity and services

Begin with the physical and link layers. Confirm power, link lights, the correct cable and transceiver, and that the switch port is enabled. Check interface errors, especially rising CRC errors, drops, or other counters; these can indicate cabling, interference, duplex, or hardware problems.

Verify that switch access or trunk mode and VLAN assignment match the design. Then check for a usable address, correct subnet mask, and reachable default gateway. An IPv4 address in the 169.254.0.0/16 range commonly indicates that a client did not obtain its expected DHCP configuration. Also consider exhausted DHCP scopes, duplicate addresses, and an incorrect gateway.

Separate name-resolution problems from basic IP connectivity. If a service works by IP address but not by hostname, investigate DNS. Confirm the client’s configured DNS server and query response, then check records, caching, and server-side service health as indicated by the evidence. Diagnosis can involve both client and server; capturing both sides while reproducing the failure can show whether a query was sent and answered.

For application-specific failures, verify that the destination is listening on the expected port and that routing and firewall rules permit the traffic. TCP attempts that receive no response, are reset, or fail only after reaching a particular network point suggest different causes. Packet captures on both ends can help establish where packets stop or whether a reset comes from the destination application. Do not infer that a server or firewall is at fault from a single timeout.

Diagnose performance faults

Define “slow” using measurements: identify the affected application, direction, time, location, and comparison with a baseline. Distinguish bandwidth (capacity) from throughput (achieved rate), latency (delay), packet loss (missing packets), and jitter (variation in delay).

High utilization can indicate congestion or contention. Poor performance isolated to one path or service may indicate a bottleneck, faulty link, routing issue, or application or server delay. Compare endpoint-to-gateway and end-to-end tests, inspect interface counters and utilization, and use traceroute or a packet capture to narrow the fault. Change one factor at a time and repeat the same measurement.

Investigate wireless faults

First identify the connection stage that fails: discovery, association, authentication, address assignment, or access to the intended service. Confirm the correct SSID, credentials and security mode, client compatibility, AP status, and DHCP or VLAN mapping.

If coverage or reliability varies by location, investigate distance, obstructions, signal degradation, roaming behavior, and interference. A Wi-Fi analyzer can help assess channel use; adjacent-channel overlap and too many clients sharing airtime can reduce performance.

Wi-Fi is a shared, half-duplex medium, so its advertised connection rate is not the same as usable application throughput. Compare measurements under similar conditions and consider client and AP capabilities, channel width, and load.

Check security and policy

A legitimate connection may be blocked by an ACL, firewall rule, network access control (NAC), 802.1X authentication, port security, or segmentation policy. Check the source and destination addresses, protocol, port, direction, and applicable rule order. Correlate timestamps with firewall, authentication, and system logs.

Distinguish an intentional deny from a misconfiguration, expired credential, or unavailable authentication service. If evidence suggests a rogue DHCP server or AP, evil twin, ARP or DNS spoofing, or another attack, preserve relevant logs and captures and follow the organization’s incident-response and escalation procedures. Do not weaken a security control as an informal test; use an authorized, scoped test and restore the approved policy.

Choose and interpret diagnostic tools

Choose the least disruptive tool that answers the question. Match the tool to the fault being tested, and treat each result as evidence rather than a complete diagnosis.

• Address and configuration: ipconfig or ip.

• Basic reachability: ping.

• Path investigation: tracert or traceroute.

• Name resolution: nslookup or dig.

• Address resolution: arp.

• Network connections: netstat.

• Packet analysis: analyzers such as tcpdump.

• Switch state: commands such as show interface, show vlan, show route, and show arp.

• Physical and wireless investigation: cable testers and Wi-Fi analyzers.

A successful ping proves only that the tested ICMP exchange succeeded at that time, not that DNS or the required application works. Use tests for the relevant service and port when application access is the question.