8 Network Testing and Troubleshooting
Learn a systematic, layer-by-layer approach to diagnosing network failures, using command-line tests and device status data to isolate physical, switching, routing, DNS, service, and wireless problems.
A process
Network troubleshooting is most effective when it follows a deliberate sequence: describe the symptom and its scope, test from the nearest layer outward, and change one thing at a time. Record affected devices, locations, times, error messages, and recent changes. Compare results with a known-working device or path, and verify any correction with the same tests that exposed the problem. A network diagram helps identify the devices and links that traffic must cross.
A sequence
Describe the failure. Determine whether service is unavailable, slow, intermittent, or limited to one application. Identify affected users, devices, network segments, and times.
Check the physical layer. Inspect power, link lights, patching, connectors, and cable routing, and confirm that the correct port is in use.
Check local configuration. Verify that the interface is enabled and that the device has the expected IP address, subnet mask, gateway, and DNS servers. For Wi-Fi, also verify the network and authentication settings.
Test progressively farther away. Check the local network interface, a nearby peer, the default gateway, a remote IP address, and then a hostname or application. This helps narrow the problem to a network segment or service.
Inspect device status and paths. Review switch-port state, VLAN membership, routes, counters, and wireless signal or event data.
Make one controlled correction and retest. Document the change and check that it has not affected other users or services.
A failed diagnostic test is a clue, not always proof of a fault. Firewalls may block ping or traceroute, and some routers do not reply to diagnostic probes even while forwarding traffic normally.
Command-line tests and what they show
Commands differ among operating systems and network-device vendors. These examples show common Windows, Linux, and Cisco IOS-style commands; consult the device documentation before using vendor-specific syntax.
Check addressing and basic reachability
On Windows:
On Linux:
Check that the address and subnet match the intended network, the gateway is reachable, and the device is using the expected interface. A Windows address beginning with 169.254 commonly indicates that the computer did not obtain an IPv4 address from DHCP. Investigate the link, VLAN, DHCP service, or relay. A successful ping to the gateway confirms only that particular IP-level test; it does not establish that DNS or an application is working.
Trace paths and test name resolution
Traceroute sends probes with increasing values to reveal responding hops along a path. Asterisks or a missing hop do not by themselves identify a broken router: a device may filter or deprioritize diagnostic replies. Compare traces to multiple destinations and investigate where results first differ from the expected path. Windows adds repeated probes and estimates loss at hops and links, but loss shown for a router’s own replies does not necessarily mean it is dropping forwarded traffic.
Use nslookup to distinguish name-resolution problems from basic IP reachability. If a destination works by IP address but not by name, check DNS servers, suffixes, and records.
Test the application service
Ping uses ICMP, while applications usually use TCP or UDP. If ping succeeds but a service fails, test the actual service port with an approved port-testing tool, then inspect host firewalls, network access controls, and the application itself. A successful ping does not prove that a TCP or UDP application port is reachable.
Cabling and physical faults
For an individual copper link, first confirm that both ends are patched to the intended devices and ports. Look for loose plugs, damaged cable, excessive bends, poorly terminated pairs, and labeling errors. Check link lights at both ends; a dark light can indicate a disconnected link, disabled port, or failed component.
Choose a cable tester that addresses the question being investigated:
A can find opens, shorts, crossed or reversed pairs, and some split-pair faults.
A checks whether a link is suitable for a target network technology or bandwidth.
A measures performance against the applicable cabling standard and limit. Continuity alone is not certification.
A can estimate the distance to a break or other fault.
If a link fails, test the permanent link and patch cords separately where practical. Re-terminate or replace the faulty section and retest. Select the correct cable category and test limit; do not declare a cable compliant based only on a basic continuity test.
Switching and VLAN problems
If a device cannot reach another device on the same LAN, investigate cabling, the switch port, VLAN assignment, and local addressing. On a managed switch, check whether the port is administratively enabled and operational, whether an access port is assigned to the expected VLAN, and whether a trunk carries the required VLANs.
Review interface counters for errors, drops, or rapidly increasing faults. Compare counters over time rather than relying on a single accumulated total. Common Cisco IOS-style checks include:
A port can appear down or inactive because it is shut down, physically disconnected, error-disabled, or associated with an unavailable VLAN. A wrong or a missing VLAN on a trunk can prevent devices from communicating even when the link is up. Match commands to the switch model and operating system.
Routing and remote connectivity
If a host can reach its local gateway but not a remote network, inspect its route and the path beyond the gateway. Confirm the destination address and subnet mask, the host’s , and the routers’ routes toward both the destination and the return path. A route in one direction is not sufficient if replies cannot return.
Common checks include:
Compare the observed route with the intended topology. A missing route, incorrect next hop, routing loop, failed interface, or filtering rule can interrupt traffic. Use traceroute to help locate where a path changes or stops, then inspect the relevant router interfaces and routing table. Do not assume that a nonresponding hop is necessarily the fault.
Wireless connectivity problems
First determine whether a wireless issue affects one client, one access point, one location, or the whole wireless network. Check that the adapter is enabled, the expected SSID is visible, and authentication succeeds. Compare the client’s signal, channel, band, and connection events at the problem location with those at a working location or client.
Weak signal, interference, poor access-point placement, unsupported bands, and authentication or profile errors can produce similar symptoms. On Windows, useful diagnostic commands include:
The can reveal visible access points, signal strength, and channel. The WLAN report summarizes recent sessions and disconnection reasons. If a connection fails, note the time and check whether the failure occurred during association or authentication. For persistent problems, collect wireless event or trace data and correlate it with the failure time. Interpret signal readings alongside the site layout and interference conditions; signal readings alone are not a complete diagnosis.
Putting the tests together
Work from the physical connection toward the application: verify cabling and link state, confirm addressing and VLANs, test the gateway and routed path, check DNS, and finally test the application’s actual port. Use cable testers for physical-link faults, switch and router commands for device state and forwarding, and wireless status and event data for Wi-Fi issues.
Interpret diagnostic output carefully. A failed ping or silent traceroute hop is not conclusive until filtering and device behavior have been considered.