Command-line diagnostic tools

Why this matters

Objective 5.5 is "given a scenario, use the appropriate tool or protocol to solve networking issues", and the operative word is appropriate. You will be given a symptom and asked which tool to reach for. Knowing what each command does is half of it; knowing what each command's failure tells you is the more useful half.

These are also the commands you will actually use. Everything in domain 5 is diagnosed with this handful.

The lesson

ping

Sends ICMP Echo Request and waits for Echo Reply. It answers one question: is that host reachable, and how long does the round trip take?

What its output tells you:

• Replies with times — the host is reachable at layer 3. Say nothing more than that: a ping reply does not mean the application works.
• Request timed out — no reply came back. The host may be down, the path may be broken, or ICMP may simply be filtered, which is extremely common on servers and firewalls. A failed ping is not proof a host is down.
• Destination host unreachable — a router on the path had no route and said so. That is a routing problem, and it is more informative than a timeout.
• TTL expired in transit — the packet's TTL hit zero, which usually means a routing loop.

The diagnostic sequence worth memorising, because it isolates the fault in four steps: ping 127.0.0.1 (the stack works), ping your own address (the interface is configured), ping the default gateway (the local network works), ping an external address (routing works), then ping an external name (DNS works). Whichever step first fails tells you where to look.

Use ping -t on Windows or plain ping on Linux for a continuous test while someone moves a cable, and ping -l / -s with a large size plus the don't-fragment flag to find an MTU problem.

traceroute / tracert

Shows the path a packet takes, hop by hop, with latency to each hop. It works by exploiting TTL: send with TTL 1 and the first router replies "time exceeded", revealing itself; TTL 2 reveals the second; and so on.

tracert on Windows uses ICMP; traceroute on Linux and macOS uses UDP by default, which matters because firewalls treat them differently and one may succeed where the other fails.

Reading the output is where the skill is:

• Where it stops is where the path breaks — which is what you were looking for.
• A jump in latency at one hop that persists for all subsequent hops indicates congestion or a long link at that point.
• Asterisks at one hop but later hops responding mean that router simply does not answer, which is normal and not a fault. Only asterisks all the way to the end indicate a real break.
• Latency at the final hop is what matters for the application; intermediate routers deprioritise generating ICMP replies, so a slow-looking middle hop is often an illusion.

pathping on Windows and mtr on Linux combine ping and traceroute, sending many probes per hop to show loss per hop over time — better for intermittent problems than a single traceroute.

nslookup and dig

Both query DNS directly, which separates a name-resolution problem from a connectivity problem.

nslookup is available everywhere including Windows, and is adequate for simple lookups: nslookup example.com resolves a name, and nslookup example.com 8.8.8.8 asks a specific server, which is how you test whether your own resolver is the problem.

dig is the better tool where available — richer, more precise output, and clearer about what is authoritative. dig example.com MX queries a record type; dig @8.8.8.8 example.com queries a specific server; dig +trace walks the delegation from the root down, which is the definitive way to see where a resolution chain breaks.

The diagnostic that matters: if the name fails but the IP address works, it is DNS. And if your resolver fails while a public resolver succeeds, the problem is your resolver, not the domain.

ip / ifconfig / ipconfig

Shows and configures local interface settings — address, mask, gateway, DNS servers, MAC address, and link state.

ipconfig on Windows, with /all for the detail that actually matters, plus /release and /renew for DHCP and /flushdns to clear a stale cache entry. ifconfig is the older Unix command, now superseded by ip (ip addr, ip route, ip link) on Linux.

This is where you confirm the addressing faults from the previous lesson: an address starting 169.254 means DHCP failed; a mask that does not match the subnet explains reaching some hosts and not others; a missing or wrong gateway explains local-only connectivity.

It is nearly always the first command to run on a complaining host.

arp

Displays and manipulates the ARP cache — the local map of IP addresses to MAC addresses.

arp -a lists it. Its diagnostic uses:

• Confirm a host on the local segment is actually responding at layer 2.
• Detect a duplicate IP address, which shows as one address flipping between two MAC addresses.
• Detect ARP poisoning, where the gateway's IP appears against an unexpected MAC — particularly if several IP addresses share one MAC.
• Clear a stale entry after a device is replaced and the IP has moved to new hardware.

netstat

Shows connections, listening ports and statistics on the local machine.

netstat -an lists all connections and listening sockets numerically; netstat -b on Windows or netstat -p on Linux names the process; netstat -r prints the routing table. On modern Linux, ss is the faster replacement with the same idea.

Use it to confirm a service is listening on the port you expect, to see whether a connection reached ESTABLISHED, and to spot unexpected listeners or outbound connections. The classic pairing: the client says connection refused, and netstat on the server shows nothing listening on that port — so the problem is the service, not the network.

tcpdump and the protocol analyzer

tcpdump captures packets from the command line. tcpdump -i eth0 host 10.1.1.5 and port 443 captures a specific conversation; -w file.pcap writes it for later analysis; -n skips name resolution so the output is not delayed or misleading.

A protocol analyzer — Wireshark being the standard — is the graphical counterpart, decoding captures into readable protocol detail with filtering, following streams, and statistics.

Reach for these when you need to see what was actually said: a failing handshake, which side sent a reset, a malformed response, retransmissions, or whether a request ever left the client at all. They are the tool of last resort because the cost is high and the output voluminous — capture narrowly.

The standing limitation: encrypted payloads stay encrypted. You see the handshake, the certificate, sizes and timing, and not the contents.

Nmap

A network scanner. It discovers which hosts are present, which ports are open, and often which service and version is behind them.

Legitimate uses: inventory and discovery, verifying that a firewall rule does what it claims, confirming a service is exposed only where it should be, and finding devices nobody documented.

The caution is genuine, and worth stating plainly: scan only networks you are authorised to scan. Scanning without permission is at best a policy violation and in many jurisdictions an offence, and it will trigger intrusion detection.

LLDP and CDP

Link Layer Discovery Protocol (LLDP)/Cisco Discovery Protocol (CDP) are layer 2 protocols by which directly connected devices announce themselves — device name, model, software version, and the port on the neighbour.

LLDP is the open standard; CDP is Cisco's. LLDP-MED extends it for IP phones, which is how a phone learns its voice VLAN and PoE requirements.

Their diagnostic value is high: they tell you what is plugged into which port without tracing a cable. "Which switch is this cable from?" is answered by one command, and they are how monitoring platforms build topology maps automatically.

Two cautions. They reveal detailed information about your infrastructure, so they are normally disabled on ports facing untrusted networks. And they only see directly connected neighbours — a device two hops away does not appear.

Speed tester

A speed tester measures achievable throughput, either to an internet service or between two internal endpoints with a tool like iPerf.

Two things to be careful about, because both produce misleading results:

The path matters. An internet speed test measures your circuit and the path to that test server and the server's own load. A poor result may be nothing to do with your network.

The client matters. A laptop on wireless, with an old NIC, or busy with other traffic, cannot demonstrate a link's capacity. Test from a wired host with headroom, and prefer iPerf between two internal hosts when you want to measure a specific link rather than the internet.

Compare against the baseline from domain 3. A number with nothing to compare it to is not a diagnosis.