Ping and Traceroute

When a service you depend on suddenly goes dark, the first question is always the same: is it on their side or yours? Sitting there wondering is a waste of time—and honestly, it’s embarrassing when someone asks if you checked the basics. This lesson shows you exactly how to test connectivity with ping and traceroute, the two commands that turn vague panic into a clear picture of where the problem lives.

The problem this lesson solves

You can’t fix a network problem if you don’t know what’s broken. Maybe a web request times out, a database connection keeps dropping, or an API only fails from the production server. Without a way to test connectivity, you’re guessing—and guessing usually makes things worse.

The real pain is the gap between "something’s wrong" and "here’s exactly what’s happening." Ping and traceroute close that gap. They give you raw, honest answers about packet loss, latency, and routing paths. With two commands, you can often tell whether the issue is your client misconfig, a firewall rule, or an upstream outage at your provider.

It’s also a skill that scales. Once you internalize how these tools think—probe, measure, compare—you’ll apply the same logic to everything: DNS, HTTP, TLS, and the telemetry stack you’re training toward.

Pro tip: If you’re feeling overwhelmed by networking jargon, don’t worry. Ping and traceroute are the friendly front door. You don’t need to know how BGP works to get a useful answer in twenty seconds.

Core concept / mental model

Think of the network as a series of connected post offices. Each post office is a router that passes your message one hop closer to the destination. Ping is like calling ahead to ask, "Hey, are you there?" Traceroute is the mail trail—it shows every post office your message passes through, and how long each one took.

Definitions you’ll actually use

• Ping: Sends an ICMP Echo Request packet to a host and waits for an Echo Reply. It measures round-trip time (RTT) and packet loss.
• Traceroute: Sends packets with increasing TTL (Time To Live) values. Each router that drops a packet because the TTL expired sends back an ICMP Time Exceeded message, revealing one hop in the path.

The mental model in one sentence

Ping tells you if you can reach a host. Traceroute tells you how you reach it.

That difference is what makes them a team. Ping answers the binary question; traceroute shows the route so you can find bottlenecks, loops, or silent drops.

Remember: fast connection ≠ good path. Lower latency can mean fewer hops, but a single broken router in the middle can ruin everything even if the end answer looks fine.

How it works step by step

Ping and traceroute aren’t magic—they’re precise, repeatable probes. Here’s the logical sequence you should follow when testing connectivity:

1. Start with local — Verify your own interface is up (ip addr or ifconfig). No point pinging Google if your NIC is down.
2. Test the gateway — Ping your router’s IP (usually 192.168.1.1 or 10.0.0.1). If this fails, your local network is the problem.
3. Test the destination — Ping the target hostname or IP. Use -c 4 to send four packets (Linux) to avoid an infinite loop.
4. If ping fails, trace the route — Run traceroute to see where the packets stop. A * * * line at hop 5 isn’t failure; it’s a router that doesn’t reply to ICMP—common and usually harmless.
5. Compare with a known-good host — Ping 8.8.8.8 (Google DNS). If that works but your target doesn’t, the problem is closer to the target, not your network.

Cause → effect chain: - Packet not reaching the gateway → your local network or interface is broken. - Packets stop at a specific router in traceroute → that router (or its firewall) is dropping you. - Packets reach the destination but reply is slow → latency or congestion on the path.

Pro tip: Always test with both a hostname and an IP. If ping google.com fails but ping 8.8.8.8 works, you’ve just diagnosed a DNS problem, not a network outage.

Hands-on walkthrough

Let’s put it into practice. These examples run on any modern Linux distro (Ubuntu, Debian, CentOS—you name it). We’re testing connectivity to a mock service, so substitute your real target as needed.

Example 1: Basic ping

ping -c 4 example.com

Expected output (edited for brevity):

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=55 time=12.3 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=55 time=12.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=55 time=12.5 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=55 time=12.4 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.3/12.5/0.2 ms

Notice the 0% packet loss and consistent 12 ms RTT—that’s a healthy connection.

Example 2: Ping with advanced flags

Use these for deeper checks:

# Flood ping (requires root) — stress test your local network
sudo ping -f -c 100 192.168.1.1

# Ping with a 1-second interval, continuous (Ctrl+C to stop)
ping -i 1 8.8.8.8

# Set packet size (useful for MTU issues)
ping -s 1472 -c 5 example.com

Example 3: Traceroute the path

traceroute -n example.com

Expected output (condensed):

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1   1.234 ms  1.198 ms  1.202 ms
 2  10.0.0.1      2.812 ms  2.765 ms  2.890 ms
 3  172.16.0.2    5.623 ms  5.611 ms  5.598 ms
 4  * * *
 5  93.184.216.34 12.345 ms  12.321 ms  12.356 ms

The * * * at hop 4 just means that router doesn’t answer ICMP—common in the wild. The 3 time values per hop are probes sent to that hop; varying times indicate fluctuating latency.

Example 4: Realistic failure scenario

ping -c 3 unreachable.service.local

If you see Destination Host Unreachable or 100% packet loss, run:

traceroute -n unreachable.service.local

If the trace stops at your gateway, the problem is upstream. If it reaches the destination but ping fails, the target host’s firewall is blocking ICMP.

Compare options / when to choose what

You’ve mastered the basics; now let’s see how ping and traceroute fit into the broader toolbox.

When to choose what: Start with ping—it’s the fastest. If it fails, escalate to traceroute to locate the break. For port-specific checks (like a database), skip ping and use nc. For sustained troubleshooting, mtr gives you a live, updating view.

Pro tip: mtr is a game-changer for intermittent issues. Run mtr -rw example.com to get a clean text report you can paste into a ticket or chat.

Troubleshooting & edge cases

Even with the right tools, things can go wrong. Here’s what actually happens and how to fix it.

ICMP blocked by firewall

• Symptom: Ping times out, but the host is up (you can SSH in).
• Fix: Use nc -zv host port or curl to test TCP ports instead. ICMP is often deprioritized intentionally for security.

Packet loss but normal latency

• Possible cause: Congestion on a specific link, or a faulty NIC.
• Action: Run ping -f -c 1000 (as root) to stress test. Watch for pattern: if loss is consistent, suspect hardware; if sporadic, likely congestion.

Traceroute shows stars but connection “works”

• Explanation: Routers that don’t send ICMP Time Exceeded replies are common. The stars aren’t always a problem.
• Action: Compare with mtr — it uses more aggressive probing and often reveals the same path with fewer gaps.

High latency, no loss

• Action: Find which hop adds the most time via traceroute. A single hop jumping from 10ms to 200ms points to a satellite link or overloaded router. Sometimes you can’t fix it—just document it.

Wrong timezone confusion

• Not a real issue with ping, but if you’re collecting metrics alongside it, always use UTC in logs. Local time only obscures cross-region troubleshooting.

What you learned & what's next

You now know how to test connectivity with ping and traceroute, from the basic ping example.com to reading traceroute hops like a pro. You can distinguish between a dead destination and a broken route, and you know when a * * * is a red herring. That’s not just a command skill—it’s a diagnostic mindset.

What you learned in this lesson:

• Ping checks if a host is reachable and measures latency and loss.
• Traceroute reveals each hop along the path, spotlighting bottlenecks and failures.
• Combining both saves hours—start with ping, escalate to traceroute, and use mtr for persistent issues.
• Firewalls can block ICMP, so always have nc or curl as fallbacks.

Your next step: Now that you can trace a path, you’re ready to dive into network telemetry and metrics ingestion—the next lesson in this track. You’ll learn how to collect these latency figures automatically and feed them into a monitoring stack, turning ad-hoc ping checks into a production dashboard. You’re building the foundation for observability, and every command you just practiced is a probe you’ll automate later.