Network Troubleshooting with Ping, Traceroute, Dig, and cURL

1. The First Question: Is the Host Reachable?

When a service is down, the first and simplest question to ask is, "Can my machine even reach the target server?" The tool for this job is ping.

ping operates at the Network Layer (Layer 3) and sends an ICMP (Internet Control Message Protocol) "Echo Request" packet to the target host. If the host is reachable and configured to respond, it sends back an "Echo Reply".

This simple exchange tells you two crucial things:

• Connectivity: A successful reply confirms that a network path exists between your machine and the target.
• Latency: The "round-trip time" (RTT) gives you a baseline for how long it takes packets to travel to the host and back.

On Linux (and macOS), ping will run continuously until you stop it with Ctrl+C. In a script or for a quick check, it's better to specify a limited number of pings using the -c (count) flag:

# Ping google.com 4 times
ping -c 4 google.com

If ping google.com fails but ping 8.8.8.8 succeeds, you've immediately isolated the problem to DNS name resolution, which we'll cover shortly. If both fail, you have a more fundamental connectivity problem.

2. The Follow-up: Where is the Connection Failing?

If ping fails with timeouts, it means your packets aren't reaching the destination or the replies aren't making it back. The next logical question is, "Where along the path are they getting lost?" For this, we use traceroute.

traceroute sends packets with progressively increasing Time-To-Live (TTL) values. Each router (or "hop") along the path decrements the TTL. When the TTL reaches zero, the router drops the packet and sends an ICMP "Time Exceeded" message back. By analyzing these responses, traceroute maps the entire route your packets take to the destination.

A common issue you'll face is that many firewalls block the ICMP packets that traceroute uses by default. A powerful technique for a DevOps engineer is to use TCP packets instead, as these are less likely to be blocked, especially on common ports like 80 or 443.

To learn more about this and other traceroute options, have a look at the following resource.

If you see * * * in the output, it means that hop did not respond. This could mean the router is configured not to send ICMP replies (stealthy) or that there's a genuine issue like high latency or packet loss at that point in the network.

3. The Name Game: Is DNS Working Correctly?

If you can ping an IP address but not a hostname, you have a name resolution problem. The tool for diagnosing this is dig (Domain Information Groper). It is far more detailed than its predecessor, nslookup, and is the standard for DNS troubleshooting on Linux.

dig allows you to query DNS servers for any type of record (A, CNAME, MX, etc.) and provides verbose output about the transaction.

The output of dig can be dense. Let's break down a typical response.

For scripting or quick checks, the +short option is your best friend:

# Get just the IP address
dig +short google.com



# 172.217.16.14

The OneUptime article we looked at earlier also has a fantastic cheat sheet for dig commands that you'll use frequently.

4. The Final Hurdle: Is the Application Itself Okay?

You've confirmed the host is reachable (ping) and DNS is resolving (dig). Yet, users still report the service is down. The problem likely lies at the application layer (Layer 7). Your tool for this is curl (client for URL).

While curl is often used to download files, it's an incredibly powerful tool for interacting with web services and APIs.

A simple curl https://api.example.com/health might tell you if the endpoint is up, but the real power for troubleshooting comes from its flags.

Using curl with these flags moves you from "is it working?" to "how and why is it failing?". For example, if you see a long time_connect, you might have a firewall issue or network congestion. If you see a long time_appconnect, there could be a problem with the TLS handshake. If both are fast but time_starttransfer is long, the problem is on the server itself—it's slow to process the request.

5. Putting It All Together: A Troubleshooting Workflow

The real skill is combining these tools into a systematic workflow. Let's walk through two common scenarios.

Let's summarize the workflow for a "service down" alert:

1. Can I resolve the hostname?

   dig service.example.com
   

   • No? It's a DNS issue. Use dig +trace to debug.

2. Can I reach the host?

   ping -c 4 <IP_from_dig>
   

   • No? It's a network path or firewall issue. Use traceroute -T -p 443 <IP> to find the breaking point.

3. Is the application port open and listening? (nc is great for this)

   nc -zv <IP_from_dig> 443
   
   
   
   # nc: connect to <IP> port 443 (tcp) failed: Connection refused
   # vs.
   # Connection to <IP> 443 port [tcp/https] succeeded!
   

   • Connection refused means the server is reachable, but nothing is listening on that port. The application is likely crashed or misconfigured.

4. Is the application responding correctly?

   curl -v https://service.example.com/health
   

   • Check the HTTP status code. Look for TLS handshake errors. See if you get a valid response body. This tells you if the application logic is working.

Conclusion

You now have a powerful and logical framework for tackling network issues. Guesswork is replaced by a systematic process of elimination, which is the hallmark of an effective DevOps engineer.

Key Takeaways:

• Troubleshooting is a flow: Start broad (is it reachable?) and progressively narrow your focus (is it DNS? is it the app?).
• ping tests basic L3 reachability and latency.
• traceroute maps the network path to find where packets are being dropped. Using TCP probes (-T) is often more reliable.
• dig is your go-to tool for all DNS diagnostics. dig +trace is your power tool for complex issues.
• curl tests the application at L7. Use -v to see connection/TLS details and -w to diagnose latency bottlenecks.

Preview of the Next Lesson:
We've traced paths and inspected traffic, and in doing so, we've implicitly interacted with devices like routers and firewalls. Our next lesson will focus on some of the most important components in a modern cloud network: Layer 4 and Layer 7 load balancers, reverse proxies, and Network Address Translation (NAT). Understanding these will add another critical layer to your networking expertise.