In this guide
1. Define the problem
“Wi-Fi is slow” is not a useful fault description. Turn it into something testable: which user, device, application, destination, location and time? Is the failure constant or intermittent? What works and what does not?
| Weak statement | Useful statement |
|---|---|
| The internet is down. | Clients in VLAN 110 receive DHCP but cannot reach 1.1.1.1. |
| Wi-Fi is slow. | Five GHz clients in one classroom show low throughput despite good RSSI. |
| The server is unreachable. | TCP/443 from subnet A to server B times out, while ICMP succeeds. |
2. Establish scope
Scope tells you where to look. Test a known-good device against the same destination and compare locations, VLANs, SSIDs, switch ports and times. If every device fails, a shared dependency is more likely. If one device fails, start locally.
Build a simple path: client → access point/switch → access layer → core/router → firewall → WAN/server. Mark the first point where expected behaviour diverges from observed behaviour.
3. Physical and link layer
Before changing IP settings, confirm the link. Check interface state, negotiated speed, duplex, errors, discards, optics, cabling and power. For wireless, check band, channel, channel width, RSSI, SNR and airtime.
Intermittent faults deserve particular attention here. A link that flaps every few minutes can create symptoms higher up that look like DHCP, routing or authentication failures.
4. Layer 2
Identify the VLAN first. Confirm the access port or SSID maps to the intended VLAN, then follow that VLAN across every trunk or uplink. Check the MAC table and STP state.
If a host's MAC address moves rapidly between ports, investigate loops, redundant paths, virtualisation, LAG configuration or a device connected in an unexpected way. If a VLAN works on one switch but not another, compare the VLAN's end-to-end tagging and allowed lists.
5. Layer 3
Once Layer 2 is proven, inspect addressing, ARP/ND, default gateway and routing. Check that the client has the expected address, mask/prefix, gateway and DNS servers.
ip addr ip route ip neigh ping <gateway> traceroute <destination>
On network equipment, inspect the routing table and forwarding entry. Remember that a route existing in a control-plane table does not guarantee successful forwarding: next-hop resolution, ACLs, firewall policy and return routing can still fail.
6. DNS, DHCP and application services
DHCP
Check whether the client received an address, gateway and DNS settings. If DHCP fails only in one VLAN, inspect the DHCP scope, relay/helper configuration and the path between the VLAN and DHCP server.
DNS
Separate name resolution from connectivity. Test the destination by IP and query DNS directly. A DNS failure can look like an application outage even when routing is completely healthy.
nslookup example.com dig example.com ping 1.1.1.1 curl -I https://example.com
7. Firewalls and ACLs
For a failed connection, write down source IP, destination IP, protocol and destination port. Then inspect the policy path in both directions. Stateful firewalls track sessions, but return traffic still needs to follow a valid route.
Do not assume “ping works” means the application path is open. ICMP and TCP/443 are different flows and may be treated differently by ACLs and security policies. Conversely, a failed ping does not prove that TCP is blocked.
8. Packet capture
Capture when configuration inspection cannot explain the behaviour. A packet capture can answer questions such as: did the client send the packet, did the gateway reply, was the TCP handshake completed, did DNS respond, or is there retransmission?
| Observation | What it suggests |
|---|---|
| No packet leaves the client | Local stack, application, interface or policy issue. |
| Packet leaves but no reply returns | Destination, routing, firewall or return-path problem. |
| SYN followed by RST | A device actively rejected or reset the connection. |
| Repeated retransmissions | Loss, congestion, filtering or an unhealthy path. |
| Duplicate IP/ARP conflict | Addressing or endpoint configuration problem. |
9. Prove the fix
A change is not a fix until the original symptom has been reproduced or understood and the corrected behaviour has been tested. Retest the failing path, a known-good path and any related service. Check that monitoring is clean and document what changed.
Where possible, reverse the change as a test. If removing the change brings the fault back, you have stronger evidence of causality than simply observing that the problem disappeared.
Engineer checklist
- What exactly fails?
- Who and what is affected?
- When did it start and is it intermittent?
- What is the expected network path?
- Where does observed behaviour first differ from expected behaviour?
- Can I reproduce it with a controlled test?
- What evidence supports my current hypothesis?
- What single test will disprove it?
- What changed immediately before the fault?
- Can I prove the fix and document it?
Key takeaways
Good troubleshooting is controlled experimentation. Define the symptom, reduce the scope, follow the traffic path, collect evidence, test hypotheses and prove the result. The goal is not merely to make the network work again; it is to understand why it failed.