Ping and Traceroute: Network Diagnostics

1. ping: Your Network Sonar

The ping command is the simplest way to check if a remote host is reachable. It works by sending a special network packet called an ICMP Echo Request to the destination. If the destination host is online and configured to respond, it sends back an ICMP Echo Reply.

To get a quick overview of what ping is and what it's used for, let's start with a video.

Basic Usage and Output

As you saw in the video, using ping is straightforward. Open your terminal and try it:

ping google.com

You'll see a continuous stream of replies. Press Ctrl+C to stop it.

Let's break down a single line of the output:
64 bytes from lhr48s15-in-f14.1e100.net (142.250.187.206): icmp_seq=1 ttl=117 time=13.6 ms

• from: The hostname and IP address of the machine that replied.
• icmp_seq: The sequence number. ping sends packets sequentially, so you can see if any were lost.
• ttl: Time To Live. This is a value that decreases at each network hop. It prevents packets from looping forever on the internet.
• time: The Round-Trip Time (RTT). This is how long it took for the packet to go to the destination and come back. This is a key measure of network latency.

When you press Ctrl+C, you get a summary:

• packet loss: The percentage of packets that were sent but never received a reply. Anything above 0% might indicate a network problem.
• rtt min/avg/max/mdev: Statistics for the round-trip time, giving you an idea of the best, worst, and average latency.

Practical ping Techniques

By default, ping on Linux runs forever. For scripting or quick tests, you often want to send a specific number of pings. You can do this with the -c (count) option.

The video you watched earlier also covers some very practical troubleshooting scenarios. Let's focus on two key ones: limiting the ping count and diagnosing DNS issues.

As demonstrated, pinging a reliable IP address like 8.8.8.8 (one of Google's public DNS servers) is a classic way to test for raw internet connectivity. If ping 8.8.8.8 works but ping google.com fails, you can be almost certain you have a DNS resolution problem, not a general network outage.

2. traceroute: Mapping the Journey

While ping tells you if you can reach a destination, traceroute shows you the path your packets take to get there. It lists all the routers (or "hops") your packet passes through on its way to the destination. This is incredibly useful for diagnosing where a network problem is located.

Installing traceroute

traceroute may not be installed on your Fedora system by default. You can install it easily using dnf.

How traceroute Works

traceroute uses a clever trick with the Time To Live (TTL) field you saw in the ping output. It sends out a series of packets.

1. The first packet has a TTL of 1. It reaches the first router, which decrements the TTL to 0. The router discards the packet and sends back an ICMP "Time Exceeded" message. traceroute now knows the address of the first hop.
2. The second packet has a TTL of 2. It passes the first router (which decrements TTL to 1) and reaches the second router. The second router decrements the TTL to 0 and sends back a "Time Exceeded" message. traceroute now knows the address of the second hop.
3. This continues, increasing the TTL by one each time, until the packet finally reaches the destination.

This video provides an excellent and detailed visual explanation of this process.

Basic Usage and Output

Now that you've installed it, run a traceroute:

traceroute google.com

Let's dissect the output for a single hop:
2 my.router.name (192.168.1.1) 1.234 ms 1.567 ms 1.890 ms

• Hop Number: 2 is the second router in the path.
• Hostname and IP: The name and IP address of the router at this hop.
• Probe Times: traceroute sends three probe packets for each hop by default. These three columns show the round-trip time for each probe.

If you see * * * for a hop, it means that router didn't respond to the probes. This could be due to a firewall or high load on the router.

3. Do-It-Yourself: Network Diagnostics

Time to apply these concepts. Open your terminal and follow along.

Task 1: Check Local and Remote Reachability

1. Ping your gateway: First, find your router's IP address with ip route | grep default. Then ping it. The time should be very low (typically < 2ms). This confirms your local network connection is working.

   
   
   
   # Example ping to a router
   ping -c 4 192.168.1.1 
   

2. Ping a remote server: Now, check your connection to the internet.

   ping -c 4 google.com
   

   Note the average time. Is it higher than the ping to your router? It should be, as the packets are traveling much farther.

Task 2: Simulate and Diagnose a DNS Failure

Let's simulate a common issue for web developers: a DNS problem. We'll use nmcli from the previous lesson to point your system to a non-existent DNS server.

1. Find your connection name:

   nmcli connection show --active
   

2. Modify the DNS server: Replace "Your-Connection-Name" with your actual connection name. We'll use an IP address that is unlikely to be a real DNS server.

   sudo nmcli connection modify "Your-Connection-Name" ipv4.dns "10.255.255.1"
   

3. Apply the change:

   sudo nmcli connection up "Your-Connection-Name"
   

4. Test and diagnose:

   • Try to ping a domain name: ping -c 4 google.com. This should fail with an error like Temporary failure in name resolution or Name or service not known.
   • Now, try to ping a public IP address: ping -c 4 1.1.1.1 (Cloudflare's DNS server). This should succeed!
   • Conclusion: You've just proven that your internet connection is working, but your system is unable to resolve domain names. This is a classic diagnostic step.

5. Revert the change: Let's fix your DNS settings.

   sudo nmcli connection modify "Your-Connection-Name" ipv4.dns "8.8.8.8 1.1.1.1"
   sudo nmcli connection up "Your-Connection-Name"
   

   Verify that you can ping google.com again.

Task 3: Trace the Path

Now, let's use traceroute to see how you connect to different parts of the world.

1. Trace to a familiar site:

   traceroute google.com
   

   Observe the path. The first hop should be your local router. The next few might be within your Internet Service Provider's (ISP) network.

2. Trace to a distant site: Let's try tracing to a server in Australia.

   traceroute unimelb.edu.au
   

   Compare this trace to the one for google.com. You should see more hops and a significant increase in latency (the ms values) as the packets cross oceans.

3. Speed up the trace: Sometimes, looking up the hostname for each hop can be slow. You can use the -n option to display only IP addresses.

   traceroute -n google.com
   

   Notice how this completes much faster.

Conclusion

In this lesson, you've added two of the most essential network diagnostic commands to your arsenal. You've not only learned what they do but also how to interpret their output to solve real-world problems.

Key Takeaways:

• ping is your go-to tool to quickly test if a host is online and responsive. It measures reachability and latency.
• traceroute maps the step-by-step path your packets take to a destination, helping you pinpoint the location of network delays or failures.
• By using ping with both domain names and IP addresses, you can effectively distinguish between network connectivity issues and DNS resolution problems.
• The TTL field in an IP packet is the key mechanism that allows traceroute to discover the path hop-by-hop.

You now have a strong grasp of Layer 3 (Network Layer) troubleshooting. In our next lesson, we will move up the networking stack to the Application Layer. You will learn to use curl to test web service availability, inspect HTTP responses, and interact with web servers directly from the command line—an indispensable skill for any web developer.