Back to all articles
TroubleshootingPingTracerouteDNSNslookupNetworking Tools

Network Troubleshooting 101: Using Ping, Traceroute, and Nslookup Like a Pro

Jamie LinMay 20, 2024

There's a common pattern with network problems. Something doesn't work. Someone who doesn't know networking stares at the screen for a while, restarts the router, restarts the computer, and either gets lucky or gives up and calls IT. And then someone who *does* know networking sits down, opens a terminal, types three commands, and in about 30 seconds says, "Oh, it's a DNS issue" or "The packet's dying at hop 6" or "The route is wrong" — and then fixes it.

The difference isn't magic. It's knowing how to use a handful of diagnostic tools that come built into every operating system. The three most essential ones are ping, traceroute (or `tracert` on Windows), and nslookup. Together, they let you systematically diagnose most network problems by working through the layers of the OSI model from the bottom up.

Let's go through each one in detail.

Ping: Is Anyone Home?

`ping` is the most basic network diagnostic tool. It tests whether a destination host is reachable over the network and measures the round-trip time (RTT) — how long it takes for a packet to travel from your machine to the destination and back.

How it works:

Ping uses the ICMP (Internet Control Message Protocol) — a protocol that lives at Layer 3 (Network Layer), the same layer as IP. When you run `ping example.com`, your computer sends ICMP Echo Request packets to the destination. If the destination is reachable and not blocking ICMP, it responds with ICMP Echo Reply packets. Ping reports how long each round trip took.

Running it:

On any operating system:

```

ping google.com

```

On Windows, ping sends 4 packets by default and stops. On Mac and Linux, it runs continuously until you press Ctrl+C (use `ping -c 4 google.com` to limit to 4 packets).

Reading the output:

```

PING google.com (142.250.185.78): 56 data bytes

64 bytes from 142.250.185.78: icmp_seq=0 ttl=116 time=12.3 ms

64 bytes from 142.250.185.78: icmp_seq=1 ttl=116 time=11.9 ms

64 bytes from 142.250.185.78: icmp_seq=2 ttl=116 time=12.1 ms

64 bytes from 142.250.185.78: icmp_seq=3 ttl=116 time=12.4 ms

```

  • **bytes from:** The destination is responding. Good.
  • **icmp_seq:** The sequence number. These should be consecutive; if you see gaps, packets are being dropped.
  • **ttl:** Time to Live. This is a counter in the IP header that decrements at each router. When it reaches 0, the packet is discarded. The value you see is what's left after the journey. You can estimate the number of hops by subtracting from a typical starting value (64, 128, or 255 depending on OS).
  • **time:** Round-trip time in milliseconds. The most important number. Low and consistent is good.

    • What different results tell you:

    *Can't resolve the hostname:* `ping` first does a DNS lookup. If you see "could not resolve hostname," the problem is DNS — the name can't be translated to an IP address. Try pinging the IP address directly to confirm the network is working; if it works, DNS is the issue.

    *Request timed out / No response:* The host didn't reply. This could mean the host is down, the host is blocking ICMP (many servers do block ping for security reasons), or there's a routing problem.

    *High latency:* If the round-trip time is consistently 200ms or more when pinging something on your local network, something is wrong. High latency to internet destinations can be normal depending on distance, but erratic or very high latency often indicates congestion or a routing problem.

    *Packet loss:* If some pings time out while others succeed, packets are being dropped somewhere along the path. This can indicate congestion, a failing network interface, a bad cable, or WiFi interference.

    Traceroute: Mapping the Path

    While ping tells you if a destination is reachable, `traceroute` (or `tracert` on Windows) shows you the entire route your packets take to get there — every router (hop) along the path — along with the round-trip time to each one.

    This is invaluable when `ping` tells you something isn't reachable. Traceroute helps you identify *where* along the path things break down.

    How it works:

    Traceroute uses a clever trick involving the TTL (Time to Live) field in IP packets. Remember that TTL decrements at each router, and when it hits zero, the router discards the packet and sends back an ICMP "Time Exceeded" message to the sender — including its own IP address in the message.

    Traceroute exploits this by:

    1. Sending a packet with TTL=1. The first router decrements it to 0, drops it, and sends back a "Time Exceeded" message. Traceroute records that router's IP address and the time it took.

    2. Sending a packet with TTL=2. It survives the first router (TTL decrements to 1) but is dropped at the second router. Traceroute records the second router.

    3. Continuing this process, incrementing TTL by 1 each time, until the destination is reached.

    The result is a map of every hop along the route.

    Running it:

    Mac/Linux: `traceroute google.com`

    Windows: `tracert google.com`

    Reading the output:

    ```

    traceroute to google.com (142.250.185.78), 30 hops max

    1 192.168.1.1 1.2 ms 1.1 ms 1.0 ms

    2 10.0.0.1 8.4 ms 8.2 ms 8.5 ms

    3 72.14.202.1 10.2 ms 9.8 ms 10.1 ms

    4 * * *

    5 142.250.185.78 12.3 ms 12.1 ms 12.4 ms

    ```

  • **Hop 1:** Almost always your default gateway (your home router). 1-2ms is normal.
  • **Hop 2:** Your ISP's first router.
  • **Subsequent hops:** The routers along the path to the destination.
  • **Asterisks (***):** This hop didn't respond. Many routers don't respond to traceroute probes for security reasons (they block ICMP TTL exceeded messages). This doesn't necessarily mean there's a problem — if the subsequent hop responds normally, the silent hop is just ignoring traceroute.
  • **Increasing RTT as hops increase:** This is normal — more hops means more travel time.

    • What traceroute tells you in practice:

    If you see that the RTT suddenly jumps dramatically at a specific hop, that's often where congestion is occurring. If you see traceroute failing completely at a specific hop and all subsequent hops also show `***`, that's where the path is breaking — the packet is dying at that router.

    If traceroute gets most of the way to the destination and then fails in the last few hops, the destination itself or the network immediately around it might be the problem.

    Nslookup: Diagnosing DNS

    `nslookup` (Name Server Lookup) is a tool for querying DNS servers directly. It's invaluable for diagnosing DNS problems.

    Running it:

    ```

    nslookup google.com

    ```

    Basic output:

    ```

    Server: 192.168.1.1

    Address: 192.168.1.1#53

    Non-authoritative answer:

    Name: google.com

    Address: 142.250.185.78

    ```

  • **Server / Address:** This is the DNS server your machine used to look up the answer. Usually your router's IP or your ISP's DNS server.
  • **Non-authoritative answer:** This means the answer came from a cache somewhere, not directly from Google's authoritative DNS servers. This is normal and expected.
  • **Name / Address:** The domain name and the IP address it resolved to.

    • Checking a specific DNS server:

    You can ask a specific DNS server instead of your default:

    ```

    nslookup google.com 8.8.8.8

    ```

    This asks Google's public DNS server (`8.8.8.8`) instead of your default. If your default DNS isn't resolving a name but `8.8.8.8` can, the problem is with your DNS configuration or your ISP's DNS.

    Checking for MX records (email-related):

    ```

    nslookup -type=MX gmail.com

    ```

    This returns the mail exchange records for gmail.com — the servers that handle incoming email for that domain.

    Interactive mode:

    Type just `nslookup` with no arguments to enter interactive mode, where you can run multiple queries. Type `exit` to leave.

    A Practical Troubleshooting Workflow

    Here's how to combine these tools systematically when something isn't working:

    Step 1: Can you reach your local network?

    `ping 192.168.1.1` (or whatever your router's IP is). If this fails, the problem is local — your network cable, your WiFi connection, or your network interface.

    Step 2: Can you reach the internet by IP?

    `ping 8.8.8.8` (Google's DNS server). If this works but step 1 failed... wait, that shouldn't happen. But if step 1 worked and this fails, the problem is with your router's connection to the internet.

    Step 3: Can you resolve DNS?

    `nslookup google.com`. If the IP ping worked but DNS fails, you have a DNS configuration issue.

    Step 4: Can you reach a website by name?

    `ping google.com`. If steps 1-3 worked, this should work too.

    Step 5: Where is the path breaking?

    If you can't reach a destination, `traceroute example.com` to see where the path dies.

    This five-step workflow — following the OSI model from the physical layer upward — resolves the vast majority of network problems quickly and methodically.

    Other Useful Tools

    While ping, traceroute, and nslookup cover most situations, a few more tools are worth knowing:

    `ipconfig` (Windows) / `ifconfig` or `ip addr` (Mac/Linux): Shows your network interface configuration — IP address, subnet mask, default gateway.

    `netstat -an`: Shows all current network connections and listening ports. Useful for seeing what your machine is connected to and what services are listening.

    `arp -a`: Shows the ARP cache — the mapping of IP addresses to MAC addresses your machine has recently discovered.

    `curl` or `wget`: Make HTTP requests from the command line. Useful for testing whether a web server is responding, even when a browser might have issues.

    The Philosophy Behind the Tools

    The reason these tools are so powerful is that they test specific things at specific layers. Ping tests Layer 3 connectivity (IP reachability). Traceroute traces the Layer 3 path. Nslookup tests the application-level DNS service. By testing each layer systematically, you can isolate exactly where a problem lives — and that almost always tells you what the fix should be.

    Network troubleshooting is part science, part detective work. These tools are your magnifying glass and your fingerprint kit. Learn to use them fluently, and you'll be the person in the room who can diagnose a network problem in 30 seconds while everyone else is still guessing.