Network Troubleshooting Tools

Why This Matters

Network troubleshooting is where theory meets reality. You can understand protocols, layers, and packet structures perfectly, but when a connection fails or performance degrades, you need practical tools to diagnose what's actually happening on the wire. These tools embody the systems approach: they let you observe behavior at different layers of the network stack, from physical connectivity to application-level data exchange.

You're being tested on more than just knowing tool names. Exams expect you to understand which tool reveals which type of problem, what layer of the network stack each tool operates on, and how to interpret the output. Don't just memorize commands. Know what each tool measures, what protocols it uses, and when you'd reach for it versus an alternative.

---

Connectivity and Reachability Testing

These tools answer the most fundamental question: can packets get from here to there? They work by sending probe packets and analyzing responses (or lack thereof), revealing whether the network path is functional and how well it's performing.

ping

• Uses ICMP Echo Request/Reply to test IP-layer connectivity between two hosts. This is the simplest reachability check available.
• Round-trip time (RTT) measurements reveal latency. High variance between successive replies often indicates congestion or route instability.
• Packet loss percentage is your first indicator of network health. Any loss above 0% warrants investigation, though keep in mind some networks rate-limit or block ICMP entirely, so a failed ping doesn't always mean the host is unreachable.

traceroute/tracert

• Exploits TTL expiration to map each router hop along the path to a destination. Each probe has its TTL incremented by one, so successive routers along the path reveal themselves by sending back ICMP Time Exceeded messages.
• Per-hop latency helps pinpoint where delays occur, not just that they exist.
• Asterisks ($*$) indicate timeouts at a given hop. This often means the router is filtering ICMP or deprioritizing it, not necessarily that the hop is down. If subsequent hops respond normally, the path is fine.

---

Name Resolution Diagnostics

Before any connection happens, domain names must resolve to IP addresses. These tools let you query DNS directly, bypassing application-level caching to see exactly what the DNS infrastructure returns.

nslookup/dig

• Queries DNS servers directly, bypassing local resolver caches so you can test what the DNS infrastructure actually returns for a given name.
• dig provides more detail than nslookup, including TTL values, authority (NS) records, the specific server that answered, and query timing. For serious DNS debugging, dig is the better choice.
• Useful for diagnosing why a hostname resolves on one machine but not another. Common culprits include stale caches, different configured nameservers, or DNS propagation delays after a record change.

---

Traffic Capture and Protocol Analysis

When you need to see exactly what's crossing the wire, packet capture tools let you inspect every byte. These operate in promiscuous mode, meaning the network interface captures all traffic it sees rather than only traffic addressed to it. This is essential for understanding protocol behavior and debugging application issues.

tcpdump/Wireshark

• Captures raw packets at the data link layer, exposing everything including Ethernet headers, IP headers, and transport-layer fields that applications normally never show you.
• Filter expressions let you isolate specific hosts, ports, or protocols from high-volume traffic streams. For example, you can filter to only see TCP traffic on port 80 to or from a specific IP.
• Wireshark's GUI makes protocol dissection visual and is great for interactive analysis. tcpdump's CLI works on headless servers and in scripts where no graphical environment is available.

netcat

• Often called the "Swiss army knife" for TCP/UDP. It creates arbitrary connections, letting you test services, transfer data, or simulate clients and servers.
• Port scanning and banner grabbing help verify what services are actually listening on a remote host and what software they're running.
• Useful for simulating protocol interactions when debugging. You can inject exactly the bytes you want and observe the response, which is invaluable for testing whether a service behaves correctly.

---

Local Configuration and State

Before blaming the network, verify your own machine's configuration. These tools show you what the local system believes about its network identity and current connections.

ifconfig/ipconfig

• Displays interface configuration: IP address, subnet mask, MAC address, and whether the interface is up or down.
• MTU settings shown here can cause subtle problems. If one link along a path has a smaller MTU than the sender expects, packets get fragmented or dropped (especially if the Don't Fragment bit is set).
• First step in troubleshooting: confirm the local machine actually has the address and settings you expect before investigating anything else.

netstat

• Lists active connections with local and remote addresses and ports, showing you what's actually connected right now.
• Listening ports reveal what services are running and potentially exposed to the network.
• Connection states like ESTABLISHED, TIME_WAIT, and CLOSE_WAIT help diagnose connection lifecycle issues. For example, a large number of connections stuck in CLOSE_WAIT suggests the local application isn't properly closing sockets.

route

• Displays the routing table, showing how the kernel decides where to forward packets for each destination network.
• Default gateway entry is critical. If this is misconfigured or missing, all traffic to non-local destinations will fail.
• Metric values determine path preference when multiple routes exist to the same destination. Lower metric means higher preference.

---

Network Discovery and Performance

These tools go beyond simple connectivity to map network topology and measure actual throughput capacity. They're essential for understanding what resources exist and how well the network performs under load.

nmap

• Active scanning discovers live hosts, open ports, and running services across a network. It sends crafted probe packets and interprets the responses.
• OS fingerprinting identifies remote operating systems by analyzing subtle differences in how their TCP/IP stacks respond (e.g., initial window size, TTL defaults, TCP options ordering).
• Security auditing is a primary use case. Finding what's exposed on your network before an attacker does is a core part of network administration.

iperf

• Measures actual throughput between two endpoints. This is real, measured performance, not the theoretical bandwidth of the link.
• TCP and UDP modes test different transport behaviors. TCP mode measures achievable throughput; UDP mode also reports jitter (variation in packet arrival times) and packet loss, which matter for real-time applications like VoIP.
• Requires an iperf process at both ends (client and server). Because you control the traffic entirely, you eliminate application-level variables and measure the network itself.

---

Quick Reference Table

---

Self-Check Questions

1. You can ping a server by IP address but not by hostname. Which tool would you use to diagnose this, and what layer of the network stack is the problem occurring at?

2. Compare tcpdump and netcat: if you needed to verify that a web server is returning the correct HTTP headers, which would you use and why?

3. A user reports slow connections to a remote server. Which two tools would you use to determine (a) where the delay is occurring and (b) what the actual throughput is?

4. What's the difference between what netstat shows you versus what ifconfig shows you? Give a scenario where you'd need information from both.

5. If traceroute shows increasing latency at hop 5 but normal times at hops 6-10, what does this tell you about where the actual bottleneck is, and why might this be misleading?