Network Troubleshooting and Tools

"Imagine you're a digital detective, following clues through tangled wires and invisible signals to solve the mystery of a slow or broken network. With the right tools and a sharp mind, no problem is unsolvable!"

On September 9, 1947, an engineer working on the Harvard Mark II computer traced a persistent malfunction back to its physical cause: a moth, trapped between the contacts of an electromechanical relay, quite literally gumming up the works. The team taped the moth into their logbook with a note that has survived as one of computing's most famous artifacts: "First actual case of bug being found." The word "bug" for a technical glitch actually predates that moment by decades — Thomas Edison used it in letters back in the 1870s — but there is something wonderful about the fact that the most famous bug in computing history was, for one glorious afternoon in 1947, an actual insect. It's a fitting origin story for this entire chapter, because troubleshooting has never really changed since that day: something is broken, the cause is hiding somewhere in a system too large to see all at once, and the only way out is to look, methodically, layer by layer, until you find it.

Why Troubleshooting Matters

Networks are like busy highways — sometimes there's a traffic jam, a roadblock, or a detour, and something that worked perfectly an hour ago simply stops working with no explanation offered. Troubleshooting is the art of finding and fixing these problems systematically rather than by superstition, and it might be the single most transferable skill in this entire field: the same small toolkit applies whether you're debugging a flaky home Wi-Fi connection or a production outage affecting a million users at three in the morning.

The most useful mental model for troubleshooting is to move layer by layer, either from the bottom up (is the physical link alive? is there IP-layer reachability? does a transport-level connection succeed? does the application protocol itself behave?) or top-down (does the app work? does the specific request work? does the raw connection work? does the network even reach the host at all?). Both directions are legitimate — bottom-up is more thorough, top-down is often faster when you already have a hunch — but jumping randomly between layers with no plan is exactly how a five-minute problem turns into an hour of increasingly frustrated guessing. Every tool in this chapter exists to answer one specific question about one specific layer, and knowing which question you're actually asking is half the skill.

Essential Troubleshooting Tools

Ping

The oldest and simplest question you can ask a remote machine is also the most literal one: are you there? That's exactly what ping does, sending an ICMP echo request and waiting to see whether an echo reply comes back.

• Try it: ping google.com
• What it doesn't tell you: Ping only confirms that ICMP traffic can reach a host and return — it says nothing about whether the service you actually care about, a web server, a database, a game server, is running or reachable, because ICMP and, say, TCP port 443 are handled completely independently by firewalls along the way.
• Where the name comes from: It's a deliberate echo, so to speak, of submarine sonar — a ping sent out into dark water, and a return echo that tells you something is out there and roughly how far away. The tool's author, Mike Muuss, wrote it in 1983 specifically to diagnose an erratic network, and reached for exactly that acoustic metaphor when naming it, because "does this respond when I call out to it" is precisely what sonar operators had been doing with actual sound waves for decades before a single packet existed.

Traceroute (tracert on Windows)

If ping tells you whether you can reach a destination, traceroute tells you the story of how you got there — every router along the way, one hop at a time, like following a package through every post office and sorting facility it passes through before reaching your door.

• Try it: tracert example.com on Windows, or traceroute example.com on Linux and macOS.
• How it actually works: Traceroute, invented by Van Jacobson in 1987 out of sheer practical necessity while diagnosing real network problems at Lawrence Berkeley National Laboratory, exploits a clever side effect of how routers already behave. It sends a series of packets with a deliberately tiny TTL (time-to-live) field, starting at 1. Every router along the path decrements the TTL by one as the packet passes through, and a router that decrements it to zero discards the packet and sends back an ICMP "time exceeded" message — accidentally revealing its own identity as the hop sitting at exactly that distance. Traceroute repeats the trick with TTL 2, then 3, and so on, mapping the entire path one confession at a time, purely by watching who complains and in what order.

ipconfig / ifconfig (or ip addr on modern Linux)

Before you can investigate anyone else, it helps to check your own papers first: what address were you assigned, what's your subnet mask, what gateway are you supposed to be using, which DNS servers were you handed.

• Try it: ipconfig on Windows, ifconfig on older Linux and macOS systems, ip addr on modern Linux.

nslookup / dig

A huge share of "the internet is broken" complaints turn out to be DNS problems wearing a disguise — the actual server is fine, but the name pointing to it has gone stale, or resolves to the wrong place, or doesn't resolve at all. These tools let you query DNS directly and cut that possibility out of the investigation immediately, rather than guessing.

• Try it: nslookup github.com, dig github.com, or dig github.com MX to check a specific record type, such as which servers handle that domain's email.

netstat (or ss on modern Linux)

This one checks all the open doors and windows in your own house: which ports are actively listening for connections, which connections are already established, and which are lingering in the process of closing.

• Try it: netstat -an
• Reading the states: LISTEN means a program is waiting for someone to connect; ESTABLISHED means an active, working conversation is underway; TIME_WAIT means a connection recently closed and is deliberately lingering for a short while to catch any stray, late-arriving packets before the operating system fully forgets about it.

Wireshark

If the tools above are a detective's magnifying glass, Wireshark is the crime lab's electron microscope: it shows you every packet that crosses an interface, byte for byte, decoded field by field.

Wireshark's own history is a small lesson in how open-source projects survive getting their name taken away from them. Gerald Combs created the tool in 1998 under the name Ethereal, while working as a network administrator frustrated by the expensive, proprietary packet analyzers of the day. Combs later left the company that had come to own the Ethereal trademark, and rather than fight over the name, the project simply relaunched under a new one in 2006: Wireshark. The shark-fin logo is a direct nod to that older name, a small visible scar from a dispute over ownership, still swimming through a tool whose entire mission has never changed: making invisible packets visible.

• What it's for: Deep packet-level analysis for the hard problems — protocol-level bugs, security investigations, working out exactly which side of a connection dropped it and why.
• Fun fact: Wireshark can decode hundreds of protocols straight out of the box, from ordinary HTTP down to obscure industrial control system protocols that most engineers will never encounter in an entire career.

curl / manual protocol probing

Sometimes the fastest way to find a problem is to stop asking a translator to do the talking and speak the protocol yourself.

• Try it: curl -v https://example.com shows the DNS lookup, the TCP connect, the TLS handshake, and the HTTP exchange all in one command, with verbose timing for each stage — extremely useful for narrowing down exactly which layer of a "the website is broken" complaint is actually the guilty party.

Troubleshooting Workflow

1. Identify the problem precisely. "The internet is down" is not a diagnosis — is it one site, one device, one app, or genuinely everything?
2. Gather information layer by layer. Is the physical link up? Was an IP address actually assigned (ipconfig / ifconfig / ip addr)? Can you reach the default gateway? Can you resolve DNS (nslookup)? Can you reach the destination IP at all (ping)? Can you reach the specific port you actually need (curl, a manual connection attempt)?
3. Isolate the issue. Is it your device, your local network, your ISP, or the remote server itself? Testing from a different device or a different network is one of the fastest ways to narrow this down to a single suspect.
4. Test a hypothesis, one change at a time. Restart a device, check a cable, adjust a firewall rule — but change exactly one variable before retesting, or you'll never know which change actually fixed anything.
5. Verify the fix, and understand why it worked. Confirming the symptom is gone is good; understanding the root cause is what prevents the exact same problem from reappearing next month, on a night when you're less in the mood to solve it.

Tool-to-Layer Cheat Sheet

Troubleshooting is the discipline of turning "it's broken" into a specific, testable claim about one layer at a time — the tool matters less than the order you reach for it.

A Case Worked End to End

Suppose a colleague messages you: "the API is down." Here is what a methodical fifteen minutes actually looks like, tool by tool, rather than a shrug and a restart.

First, narrow the claim. Is it down for everyone, or just them? A quick message to someone else on a different network settles that in seconds. Say it's everyone — the investigation moves to the server side. ping api.example.com comes back clean, so the machine is alive and IP-reachable; whatever's wrong, it isn't a dead server or a severed cable. nslookup api.example.com resolves to the expected address, so it isn't a stale DNS record pointing somewhere abandoned. netstat -an on the server itself, if you have access, shows the process is listening on the right port — so the program hasn't crashed outright. That narrows things sharply: the machine is up, DNS is correct, and the process is listening, yet something is still wrong.

The next move is curl -v https://api.example.com/health, and this is where the real answer tends to hide. Maybe the TCP connection succeeds instantly but the TLS handshake stalls — a certificate that quietly expired overnight. Maybe the connection and handshake both succeed, but the HTTP response takes eleven full seconds to arrive — not "down" at all, but a database query somewhere upstream grinding to a halt under load. Two completely different root causes, both reported by a human as "the API is down," and both distinguishable in under a minute once you stop guessing and start asking each layer its own specific question in order.

Frequently Asked Questions

If ping succeeds, why would someone still insist the network is the problem? Because a successful ping only proves that ICMP traffic can reach a host and come back, and plenty of very real outages leave ICMP completely untouched while the actual service — a web server, a database, an application process — is either crashed or blocked at a different port entirely. The chapter's warning box on this is there specifically because it's one of the most common ways an investigation stalls: someone declares "the server responds, so it's not a network problem" and stops looking exactly one layer too early.

Why does traceroute sometimes show a hop as * * * even when the connection past it works fine? Because some routers deliberately deprioritize the ICMP "time exceeded" replies traceroute depends on, since answering those messages isn't their actual job and can even be treated as a minor security risk to expose. A silent hop doesn't mean a broken hop — it just means that particular router chose not to confess its identity, while every packet destined further down the path keeps moving through it perfectly normally.

Should troubleshooting always start from Layer 1 and work upward? Not necessarily — the chapter presents bottom-up and top-down as equally legitimate, just suited to different situations. Bottom-up is the thorough, no-assumptions approach, useful when you genuinely have no idea where the fault lies. Top-down is faster when you already have a hunch, like a colleague reporting a specific broken feature, because you can jump straight to testing the application layer first and only dig deeper if that layer turns out to be innocent.

In the "the API is down" walkthrough, why bother checking DNS and the listening port at all once ping already succeeds? Because each of those checks rules out a different, otherwise-plausible cause, and skipping any one of them leaves a gap an actual outage could be hiding in. A clean ping only proves the machine is alive; a correct DNS answer only proves the name isn't stale; a listening port only proves the process hasn't crashed outright — none of those three facts, even together, guarantees the service itself is healthy, which is exactly why the investigation still has to reach curl -v before it finds the real answer.

Is memorizing every flag for every tool in this chapter actually the point? No — the chapter's closing axiom says this outright: the tool matters less than the order you reach for it. What actually matters is knowing which specific question belongs to which layer, so that "the internet is broken" turns into a sequence of small, testable claims you can confirm or rule out one at a time, the same discipline that turned a literal moth in a relay into the most famous bug report in computing history.

Fun Facts & Memes

• The Harvard Mark II moth wasn't the first use of the word "bug" for a glitch, but it is almost certainly the only time in history the bug in question could be pressed flat and taped into a logbook as physical evidence.
• "Have you tried turning it off and on again?" remains one of the most effective fixes in the history of technology, because a restart resets accumulated state that a careful layer-by-layer check might otherwise take much longer to catch.
• Traceroute's core trick — deliberately expiring a packet's TTL to make a router reveal itself — was, in its own small way, exactly as clever a piece of lateral thinking as tricking a fortress guard into announcing his own position by shouting back at an intruder he thought he'd caught.
• Wireshark's predecessor Ethereal and its successor Wireshark have, between them, been quietly decoding the internet's traffic for well over a quarter of a century, under two different names but one unbroken mission.

The next time something breaks, resist the urge to guess. Open a terminal, run ping, then traceroute, then curl -v, in that order, and let the layers tell you their own story — the same way that moth, pressed flat in a logbook in 1947, told an entire team exactly where to look.