FAULT FINDING
Network Fault-Finding Playbook
A disciplined installer workflow for isolating faults without swapping random equipment or changing several variables at once.
Rule 1: capture the failure before fixing it
Record the time, endpoint, switch port, IP details, link speed, interface counters, PoE state and user symptom. Once the fault is gone, much of the evidence disappears.
Rule 2: test from physical to application
| Stage | Question | Evidence |
|---|---|---|
| Power | Is the endpoint powered and stable? | LEDs, PoE state, UPS logs. |
| Physical | Is the link electrically/optically sound? | Wiremap, certification, fibre inspection, optical test. |
| Ethernet | What speed/duplex was negotiated? | Switch interface status and counters. |
| VLAN | Is the port in the intended network? | Access/trunk config, VLAN table. |
| IP | Does the endpoint have valid addressing? | IP, mask/prefix, gateway, DHCP lease. |
| Routing/DNS | Can it reach gateway, remote IP, DNS? | Ping, ARP/ND, route, DNS lookup. |
| Application | Is the service itself listening/allowed? | Port test, server logs, firewall logs. |
Change one thing at a time
If you replace the patch lead, move the switch port, reboot the switch and change the VLAN all at once, you may restore service without learning the cause. Controlled changes create evidence that can be reused when the fault returns.
Use counters, not impressions
CRC/FCS errors, discards, link flaps and PoE faults are more useful than "the cable looks okay". Record counter values, wait during a failing condition, then compare again.
Intermittent faults need timestamps
Correlate endpoint failure time with switch logs, PoE events, DHCP logs, AP logs, UPS events and server/application events. A precise timestamp turns multiple independent systems into one timeline.
Known-good substitution
Substitution is powerful when controlled. Use a known-good patch lead, port or transceiver one at a time. If the problem follows the component, you have stronger evidence. If it stays with the path, continue along the path.
Client benefit
A documented fault process reduces downtime and prevents the same issue from being rediscovered every time a different technician attends site.
Training manual: build evidence before changing configuration
Five-minute triage sheet
| Check | Record |
|---|---|
| Physical | Link LED, media, patch path, cable/fibre ID. |
| Switch | Port, speed, duplex, VLAN, errors, PoE state. |
| Endpoint | IP, prefix/mask, gateway, DNS, DHCP/static. |
| Reachability | Gateway ping, remote IP, DNS lookup, application port. |
| Time | Exact timestamp and whether fault is constant/intermittent. |
Example isolation sequence
Symptom: PC says "connected" but cannot browse.
- Confirm negotiated Ethernet speed and error counters.
- Record IP address, subnet and gateway.
- Ping the default gateway by IP.
- If gateway fails, inspect VLAN, ARP and local Layer 2 path.
- If gateway works, ping a known remote IP.
- If remote IP works but names fail, test DNS.
- If DNS works but the application fails, test the service/port and firewall path.
Baseline values matter
An interface showing 100 CRC errors is not enough by itself. Record the counter, generate or observe normal traffic for a known interval, then check whether the counter is increasing. A static historical number and a rapidly growing error count mean different things.
What works
- Exact timestamps.
- One variable changed at a time.
- Known-good substitution.
- Native cable/fibre test evidence.
- Before-and-after counter snapshots.
What wastes time
- Rebooting before collecting logs.
- Resetting a switch to factory defaults for a single-port problem.
- Changing VLAN, cable and IP settings simultaneously.
- Blaming DNS before confirming basic IP reachability.