What network troubleshooting means
Network troubleshooting is not a collection of commands to try until the symptom disappears. It is a controlled process for turning an observed failure into a tested explanation. The goal is to narrow the problem, collect evidence, identify the failing dependency, and validate that the corrective change fixes the original symptom without creating another one.
A useful diagnosis separates symptoms from causes. “The website does not load” may describe DNS failure, an unreachable gateway, asymmetric routing, a firewall rule, packet loss, or the application itself. Start with what the user can and cannot do, then convert that report into technical tests.
Before changing anything: scope, impact, and recent changes
Define the scope before touching configuration. Is one host affected, one VLAN, one site, one application, or every user? Determine when the problem started, whether it is constant or intermittent, and whether any maintenance, policy change, software upgrade, cable move, or provider event occurred around the same time.
Capture the current state when possible. Interface status, routing tables, neighbor entries, DHCP leases, DNS answers, firewall counters, and timestamps may change after a restart or configuration edit. Preserving evidence makes root-cause analysis much easier and gives you a baseline for rollback.
A layered and plane-based method
A layered approach prevents jumping directly to an application symptom when the actual fault is lower in the stack. Validate physical connectivity and Layer 2 first, then addressing, neighbor discovery, routing, policies, transport behavior, and finally the service itself. You can also think in terms of data, control, and management planes when diagnosing infrastructure devices.
The order is not a rigid ritual. If monitoring clearly shows a BGP withdrawal, start there. The value of the model is that it gives you a complete checklist and keeps you from forgetting dependencies that are easy to overlook under pressure.
1. Physical and link layers
Verify that interfaces are administratively and operationally up, the expected speed and duplex are negotiated, and error counters are not increasing. Check optics, cables, radio conditions, VLAN membership, trunk allowance, spanning-tree state, and link aggregation when they apply.
A link can be “up” and still be unhealthy. CRC errors, drops, duplex mismatch, unstable Wi-Fi, an incorrect native VLAN, or a blocked STP port may create partial or intermittent symptoms that look like higher-layer failures.
2. IP addressing and neighbors
Confirm the host address, prefix length, default gateway, and DNS configuration. Then validate ARP for IPv4 or Neighbor Discovery for IPv6. A correct IP address is not enough if the host resolves the wrong MAC address, cannot reach its gateway, or has a duplicate address.
Compare expected and observed neighbor entries. If a host cannot resolve the gateway, focus on the local segment. If neighbor resolution succeeds but remote traffic fails, move upward to routing and policy.
3. Routing and the forward/return path
Inspect the routing decision at every important hop: destination prefix, longest-prefix match, next hop, outgoing interface, and any dynamic protocol state. Troubleshooting must include the return path because many failures are asymmetric. The request may reach a server while the reply follows a different route and is filtered or translated incorrectly.
Traceroute-style tools provide clues, not absolute truth. Devices can rate-limit or block probe responses while forwarding production traffic normally. Combine path tests with routing tables, counters, and packet captures when needed.
4. ACLs, firewalls, and NAT/PAT
Once connectivity exists, verify the policies that may alter or filter the flow. Check ACL direction and order, firewall zones and session state, NAT/PAT rules, translations, and any policy-based routing. A rule can be syntactically valid yet applied on the wrong interface or in the wrong direction.
Use counters and logs whenever possible. They tell you whether the packet reached the policy, matched the intended entry, was denied, or was translated. This is much stronger evidence than changing rules until traffic starts passing.
5. Services: DHCP, DNS, and time
Separate IP connectivity from service behavior. For DHCP, verify the client VLAN, relay, scope, lease availability, and options. For DNS, compare answers from the expected resolver and authoritative sources. For NTP, check reachability, source selection, offset, and whether the clock is actually synchronized.
A service failure may affect only one dependency while basic routing remains healthy. A user who can ping an IP address but not open a hostname gives you a very different diagnostic path from a user who cannot reach the default gateway.
Tools: from commands to packet captures
Choose tools based on the question you need to answer. Interface and route commands show local state; ping tests reachability and round-trip behavior; traceroute explores path behavior; DNS utilities expose resolver answers; socket tools show listeners and connections; packet captures reveal what was actually sent and received.
The next guides cover diagnostic commands and Wireshark in more detail. Use them to confirm a hypothesis rather than to generate more noise.
Latency, loss, jitter, and throughput
Performance incidents require measurements, not only reachability tests. Latency is delay, packet loss is missing traffic, jitter is variation in delay, and throughput is delivered data over time. They interact but are not interchangeable. A path may have acceptable average latency while short bursts of loss make voice or interactive sessions unusable.
Measure close to the affected application and compare against a baseline. Interface utilization, queue drops, retransmissions, radio retries, and provider statistics help locate where degradation begins.
How to handle intermittent faults
Intermittent failures are difficult because the evidence may disappear before you investigate. Increase observability before making changes: collect logs, time-series counters, reachability probes, packet samples, and configuration-change history. Accurate time synchronization becomes especially important when correlating events across devices.
Look for patterns such as a specific time of day, link utilization threshold, lease renewal, routing reconvergence, wireless roaming event, or scheduled job. The pattern often narrows the fault domain more effectively than a one-time manual test.
Recommended diagnostic workflow
Start by reproducing the symptom and defining success. Scope affected users and destinations, identify recent changes, and establish a known-good comparison when possible. Validate the local link and addressing, then the gateway, path, policy, transport, and service. At each step write down what the test proved and what it did not prove.
Form one hypothesis at a time. Choose the smallest test or reversible change that can confirm or reject it. After the fix, repeat the original test and monitor long enough to ensure the fault does not return.
Common troubleshooting mistakes
Frequent mistakes include changing multiple variables at once, assuming ping proves an application works, ignoring the return path, rebooting before preserving evidence, trusting a single monitoring view, or treating correlation as causation. Another common error is blaming DNS, the firewall, or “the network” before defining the actual failed flow.
Good troubleshooting is conservative: collect evidence first, prefer reversible changes, and keep a clear distinction between observation, hypothesis, action, and result.
Document the cause, change, and validation
A resolved incident should leave behind useful information. Record the scope, timeline, evidence, root cause, corrective action, rollback plan if relevant, and the test that proved recovery. If the issue exposed a monitoring or design gap, capture that as a follow-up action.
Documentation reduces repeat incidents and makes the next diagnosis faster. It also distinguishes a temporary workaround from a permanent fix.
References and next step
The troubleshooting process combines concepts covered throughout SubnetMaster: Ethernet and switching, IP addressing, routing, network services, QoS, and security controls. Vendor command syntax differs, but the dependency model remains the same.
Continue with network diagnostic commands, then move to Wireshark packet analysis when you need packet-level evidence.