Network Troubleshooting in Practice - Diagnosing Issues with ping, traceroute, and dig

Network Troubleshooting in Practice - Diagnosing Issues with ping, traceroute, and dig
Reading time: About 12 min Difficulty: Intermediate

What You'll Solve with This Article

"Can't reach the site." "Only this one server is unreachable." Network failures are 90% diagnosis. With ping, traceroute, and dig, you can systematically narrow down the problem by checking reachability → routing → DNS in order.

The Diagnosis Pattern (3 Steps for Real-World Use)

  1. ping to check reachability
  2. traceroute to find where packets stop
  3. dig to verify DNS resolution

Environment Requirements

  • OS: Ubuntu or RHEL-based Linux
  • CLI access available

1. ping — How Do You Check Reachability?

ping is the first tool to confirm whether packets reach the destination. Testing with an IP address lets you separate DNS problems from routing problems.

$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=8.45 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=7.92 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=8.21 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=8.10 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 7.920/8.170/8.450/0.196 ms

Reading ping Output

Result Meaning
Responses received (0% loss) Physical connection and routing are working
100% packet loss Routing problem or firewall blocking ICMP
Request timeout Remote host rejects ICMP, or path has a problem

Check External and Internal Separately

# Step 1: Can you reach the local gateway?
$ ping -c 4 192.168.1.1

# Step 2: Can you reach an ISP DNS? (confirms internet connectivity)
$ ping -c 4 8.8.8.8

# Step 3: Can you ping by hostname? (confirms DNS resolution works)
$ ping -c 4 google.com

If Step 2 succeeds but Step 3 fails, the problem is DNS.

Use -c 4 to limit the number of packets. Without it, ping runs forever until you press Ctrl+C — always use -c in scripts or quick checks.

2. traceroute — Where Does the Packet Stop?

When the destination is unreachable, use traceroute to identify which hop is dropping packets.

$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.234 ms  1.145 ms  1.089 ms
 2  10.0.0.1 (10.0.0.1)  8.456 ms  8.512 ms  8.398 ms
 3  * * *
 4  203.0.113.1 (203.0.113.1)  15.234 ms  15.198 ms  15.321 ms
 5  8.8.8.8 (8.8.8.8)  22.567 ms  22.489 ms  22.601 ms

What Does * * * Mean?

* * * means that router did not return an ICMP Time Exceeded message. This is not necessarily a failure. If packets reach hops beyond that router, it's simply configured to drop ICMP responses.

When * * * continues from some hop onward and never reaches the destination, packets are likely being dropped at or after that point.

Installing traceroute

It may not be installed by default on Ubuntu:

$ sudo apt install traceroute

mtr is a popular alternative that continuously monitors the path and shows per-hop packet loss in real time:

$ sudo apt install mtr
$ mtr 8.8.8.8

3. dig — How Do You Verify DNS Resolution?

When you can reach an IP address but not a hostname, the problem is DNS. Use dig to inspect the name resolution in detail.

Basic Usage

# Look up A record (IPv4 address)
$ dig google.com A

# Compact output — just the answer
$ dig +short google.com
142.250.196.46
# Query a specific DNS server directly (isolates the DNS server itself)
$ dig @8.8.8.8 google.com A

Reading dig Output

$ dig google.com A
; <<>> DiG 9.18.18 <<>> google.com A
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             83      IN      A       142.250.196.46

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
  • An entry in ANSWER SECTION means DNS resolution succeeded
  • NXDOMAIN means the domain does not exist (or is misspelled)
  • SERVFAIL means the DNS server failed to return a response

DNS Record Types and How to Query Them

Record Purpose Example command
A IPv4 address dig example.com A
AAAA IPv6 address dig example.com AAAA
MX Mail server dig example.com MX
CNAME Alias dig example.com CNAME
NS Name server dig example.com NS
PTR Reverse lookup dig -x 8.8.8.8

4. Diagnosis Flow — Real-World Patterns

The goal is to narrow down which layer the failure is at. Work through this sequence:

Step 1: Does ping to an IP address succeed?

$ ping -c 4 8.8.8.8

If not, it's an L3 routing problem. Use traceroute to find where packets stop.

Step 2: Does ping to a hostname succeed?

$ ping -c 4 google.com

If the IP works but the hostname fails, it's a DNS problem. Investigate with dig.

Step 3: Does dig resolve the name?

$ dig @8.8.8.8 google.com

If 8.8.8.8 resolves it but your configured DNS server doesn't, the issue is in /etc/resolv.conf or the DNS server itself.

Common Failure Patterns and Fixes

Pattern 1: Gateway reachable, but no internet access

$ ping -c 4 192.168.1.1   # OK
$ ping -c 4 8.8.8.8       # Fails

Router misconfiguration or ISP issue. Use traceroute to see how far packets travel.

Pattern 2: IP reachable, but hostname resolution fails

$ ping -c 4 8.8.8.8          # OK
$ ping -c 4 google.com       # Fails

DNS problem. Check /etc/resolv.conf and try an alternative DNS server.

$ cat /etc/resolv.conf
$ dig @8.8.8.8 google.com
$ dig @1.1.1.1 google.com

Pattern 3: A specific port is unreachable

$ ping -c 4 example.com     # OK (ICMP works)
$ curl -v https://example.com  # Fails (port 443 blocked)

Firewall issue. Check ufw, firewalld, or iptables.

$ sudo ufw status

ICMP (ping) passing does not mean HTTP/HTTPS will pass — they are different protocols at different layers. For port-level connectivity, use nc (netcat) or curl -v.

5. When systemd-resolved Interferes

On Ubuntu 18.04 and later, systemd-resolved acts as a DNS resolver intermediary. When dig shows the server as 127.0.0.53, queries are going through systemd-resolved.

# Check the current DNS configuration
$ resolvectl status

# Query an external DNS directly to compare
$ dig @8.8.8.8 google.com

If 8.8.8.8 resolves names but 127.0.0.53 does not, the issue lies in systemd-resolved's configuration or the /etc/resolv.conf symlink.

# Check what /etc/resolv.conf points to
$ ls -la /etc/resolv.conf

The normal state is for /etc/resolv.conf to be a symlink to stub-resolv.conf (managed by systemd-resolved). If it points elsewhere or is a plain file, DNS behavior may be unexpected.

Next Reading