A tool is useful only when its output can change the next decision. Running every command you remember produces noise and makes it harder to preserve a clean troubleshooting sequence.
State the theory first. Then ask what result would support it and what result would reject it. Choose the least disruptive tool that can collect that evidence.
Fast rule: Configuration tools show what the host believes. Reachability tools test a path. Name-resolution tools test DNS. Packet tools show traffic. Physical tools test the medium.
Method before tool
A practical sequence is:
- Identify the problem and its scope.
- Establish a theory.
- Test the theory with targeted evidence.
- Plan and implement the fix.
- Verify full functionality and consider preventive action.
- Document the findings and change.
Suppose one workstation cannot reach an internal application. Checking the workstation's address, prefix, gateway, and DNS servers is a better first move than scanning the entire network. If every workstation in the VLAN fails, the scope changes and so should the tools.
Command-line tools at a glance
| Tool | Best use | Evidence | Caution |
|---|---|---|---|
| ipconfig, ifconfig, ip | Inspect local interface configuration | Addresses, prefixes, gateways, DNS, interface state | Command and fields vary by operating system |
| ping | Test basic IP reachability and round-trip behavior | Replies, loss, latency | Filtering can block ICMP even when the service works |
| traceroute or tracert | Observe where a routed path changes or stops responding | Hop sequence and per-hop timing | Silent hops do not always mean forwarding stopped |
| nslookup or dig | Query DNS records and servers | Returned records, server used, response status | A correct record does not prove the application is healthy |
| arp or ip neigh | Inspect local IP-to-link-layer neighbor mappings | Address mappings and neighbor state | Only applies to the local link or cached neighbors |
| netstat or ss | Inspect local sockets and connections | Listening ports, endpoints, connection states | Does not by itself prove a firewall permits remote access |
| route or ip route | Inspect local routing decisions | Connected routes, default route, next hops, metrics | A route can exist while the next hop is unreachable |
| tcpdump or protocol analyzer | Inspect packets and protocol exchanges | Headers, flags, timing, retransmissions, requests, responses | Capture placement and encryption matter |
Local configuration tools
Use ipconfig on Windows or ip and, on older systems, ifconfig on Unix-like systems to inspect the local interface. Look for:
- Correct address and prefix
- Expected default gateway
- Expected DNS servers
- DHCP versus static configuration
- Link state
- An Automatic Private IP Addressing (APIPA) address in 169.254.0.0/16
An APIPA address suggests that the host did not receive a normal IPv4 lease. It does not identify the exact failure. The DHCP server, relay, VLAN, switchport, or client may be involved.
Use the routing-table command when the host can reach local systems but not remote networks. Confirm the default route and any more-specific route that could override it.
Reachability and path tools
ping commonly uses Internet Control Message Protocol (ICMP) echo messages. Test in a useful order:
- Loopback or local stack
- Local interface address
- Default gateway
- Remote IP address
- Remote hostname
This order separates local configuration, local-link access, routing, and name resolution. Do not treat one failed ping as proof that the destination is down. Firewalls may block ICMP while allowing the actual application.
traceroute or Windows tracert reveals the sequence of responding hops by manipulating the IP time-to-live or hop limit. It helps locate where behavior changes. A hop that does not reply may still forward traffic, so continue reading the later hops.
Name-resolution tools
Use nslookup or dig when an IP address works but a hostname does not, or when a DNS record is suspected.
Useful checks include:
- Query the expected record type
- Confirm which resolver answered
- Compare an internal resolver with an external resolver when appropriate
- Check whether the returned address is current
- Look for
NXDOMAIN, timeout, or server-failure responses
DNS success proves that a name resolved to data. It does not prove that the destination accepts connections or serves the correct application.
Connections, sockets, and neighbors
Use netstat or ss to determine whether a local service is listening and whether a connection is established, waiting, or closing. A service listening only on 127.0.0.1 is not reachable through the host's network address.
Use arp or ip neigh to inspect local neighbor mappings. Duplicate or changing mappings may support an address-conflict or spoofing theory. A missing entry may simply mean the host has not attempted local communication yet.
Use route or ip route to identify the next-hop decision. Compare the destination with the route prefix and metric rather than checking only for a default route.
Packet analyzers, captures, and scanners
A protocol analyzer helps answer packet-level questions. It can show whether a SYN received a SYN-ACK, whether DNS replied, whether DHCP completed, and whether retransmissions increased.
A port scanner tests which services respond from the scanner's observation point. It is useful when authorized and scoped. An open port identifies a reachable listener, not whether the service is secure or correctly configured.
A network tap or mirrored switchport supplies traffic to a capture or sensor. The tap or mirror is the observation method; the analyzer interprets the traffic.
Copper cabling tools
| Tool | Best use | Typical finding |
|---|---|---|
| Cable tester | Check continuity and wire-map faults | Open, short, reversal, crossed pair, split pair depending on tester |
| Toner and probe | Identify which cable or termination belongs to a run | Physical cable location |
| Time-domain reflectometer | Estimate the distance to an impedance change in copper | Approximate location of an open, short, or damaged section |
| Loopback plug | Test a port's transmit and receive path | Whether the interface can send and receive locally |
A toner does not certify cable performance. A basic continuity test does not prove the run meets a category's bandwidth and crosstalk requirements. Match the tool to the question.
Fiber tools
Optical time-domain reflectometer (OTDR): sends light pulses and analyzes reflections to estimate distance to fiber events such as breaks, bends, splices, or connectors.
Optical power meter and light source: measure received optical power and loss across a link.
Visual fault locator (VFL): sends visible light to help identify a fiber or reveal some nearby breaks and severe bends. It is practical for short-range visual work, not a replacement for complete optical testing.
Inspect and clean fiber connectors before repeatedly replacing optics. Contamination can create loss that looks like a transceiver or cable failure.
Wireless tools
A Wi-Fi analyzer can show service set identifiers, channels, channel widths, signal levels, and nearby networks. Use it to investigate overlap, congestion, weak coverage, or unexpected access points.
A wireless survey maps coverage and interference in the actual environment. A strong signal does not guarantee good performance if the channel is crowded or the noise floor is high.
A spectrum analyzer observes radio-frequency energy, including non-Wi-Fi interference. It is the stronger choice when the suspected source may be a microwave oven, cordless device, or another radio technology.
Scenario comparisons
One user receives 169.254.20.8
Start with local configuration and switchport/VLAN evidence. Confirm the host attempted DHCP, then test the path to the DHCP server or relay. A packet capture may be useful if the discover or offer sequence is unclear.
A hostname fails, but the server IP works
Use nslookup or dig. A cable tester does not address the evidence. A successful ping to the IP already supports basic reachability.
A copper run fails, and the technician needs the fault location
Use a TDR. A toner identifies the cable, while a basic tester may identify an open without estimating its distance.
Users report intermittent wireless slowness near lunch time
Use a Wi-Fi analyzer and compare the result with a baseline. If the interference appears non-Wi-Fi, move to a spectrum analyzer.
A server claims to listen on TCP 443, but remote clients time out
Use netstat or ss locally to confirm the listener and binding, then test reachability and inspect firewall or packet evidence from the correct path.
Common exam traps
- Choosing traceroute to test DNS.
- Treating a failed ping as proof that an application is down.
- Using a toner when the question asks for distance to a cable fault.
- Using an OTDR on copper or a TDR on fiber.
- Treating a listening socket as proof that remote traffic is permitted.
- Running a packet capture before checking obvious local configuration.
- Replacing equipment before documenting the baseline and scope.
Rapid review grid
| Need | Tool |
|---|---|
| Local address, gateway, and DNS | ipconfig, ip, or ifconfig |
| Basic IP reachability | ping |
| Routed hop sequence | traceroute or tracert |
| DNS record and resolver response | dig or nslookup |
| Local listening ports and connection state | ss or netstat |
| Locate a copper run | toner and probe |
| Distance to copper fault | TDR |
| Distance to fiber event | OTDR |
| Wi-Fi channels and signal | Wi-Fi analyzer |
| Non-Wi-Fi radio interference | Spectrum analyzer |