Basic Network Troubleshooting - ping, traceroute, ss, dig

2026-05-30 Reading time: About 14 min Difficulty: Intermediate

What You Will Achieve

• Check connectivity to a host with ping and control the count with -c
• Locate where traffic stops with traceroute / tracepath
• Check listening ports and connection states with ss, and explain its relation to netstat
• Check IP settings and routing with ip addr / ip route
• Isolate DNS name-resolution success or failure with dig / host
• Troubleshoot layer by layer, from the physical layer up to DNS and the application layer

This is the core of LPIC-1 objective 109.3 "Solve basic network problems". It is the skill of narrowing "it doesn't connect" down to a cause through per-layer checks instead of guesswork.

In What Order Should You Isolate Faults?

Network faults reach their cause fastest when you check from the lower layers up to the higher ones. If a lower layer is broken, the layers above always fail, so clearing faults from the bottom is the rule.

If "a website is unreachable", first check raw connectivity with an IP literal like ping 8.8.8.8, then check name resolution with ping example.com. If the IP works but the domain does not, you have isolated the problem to DNS in one step.

Steps

Step 1: Check the interface and IP

ip link show
ip addr show

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.1.20/24 brd 192.168.1.255 scope global enp0s3

ip link shows the state of network devices (link layer). If UP and LOWER_UP are present, the link is alive. Use ip addr to confirm an IP address (inet 192.168.1.20/24) is assigned. If no address is assigned, checking anything above this is pointless.

Step 2: Check routing and the gateway

ip route show

default via 192.168.1.1 dev enp0s3 proto dhcp metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.20

ip route shows the routing table. default via 192.168.1.1 is the default gateway. Without this line you cannot leave the local network (reach the internet). Most "the LAN works but I can't get out" faults are caused right here.

Step 3: Check connectivity with ping

ping -c 4 192.168.1.1
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=115 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.8 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

ping checks connectivity with ICMP ECHO packets. -c 4 means "stop after sending 4 packets" (man ping: "Stop after sending count ECHO_REQUEST packets"). Without it, ping keeps sending until Ctrl+C. The interval is set with -i in seconds, defaulting to 1 second. Check the gateway first, then an external IP.

Step 4: Trace the route with traceroute

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)  0.8 ms  0.7 ms  0.7 ms
 2  10.0.0.1 (10.0.0.1)  8.2 ms  8.1 ms  8.0 ms
 3  * * *
 4  8.8.8.8 (8.8.8.8)  12.1 ms  12.0 ms  11.9 ms

traceroute shows each hop (router) along the route to the destination in order (man: "tracks the route packets taken ... on their way to a given host"). If it stops at a hop, everything up to that point is connected. * * * indicates that the hop "did not respond within the timeout"; it is not necessarily a fault, since routers that do not return ICMP also show it.

To run as an unprivileged user, or to also learn the path MTU, use tracepath. Per man tracepath, "tracepath is not a privileged program, unlike traceroute".

tracepath example.com

Step 5: Check DNS with dig / host

dig example.com
dig +short example.com

;; ANSWER SECTION:
example.com.		3600	IN	A	93.184.216.34

93.184.216.34

dig shows the details of a DNS query. The basic syntax is dig @server name type (BIND 9 official). If the ANSWER SECTION shows a result (a resource record), name resolution succeeded. +short gives terse output, returning just the value.

dig MX example.com
dig -x 93.184.216.34
host example.com

To specify a record type, add the type (dig MX example.com). -x performs a reverse lookup (PTR) from an IP to a hostname. host is a simpler DNS lookup utility; host name alone reports A, AAAA, and MX together.

Step 6: Check listening ports and connections with ss

ss -tulnp

Netid State   Local Address:Port   Peer Address:Port  Process
tcp   LISTEN  0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=812,fd=3))
tcp   LISTEN  0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=940,fd=6))
udp   UNCONN  0.0.0.0:68           0.0.0.0:*

ss shows socket statistics. The meaning of the common combination -tulnp, per man ss, is as follows.

When "I started a service but cannot connect", use ss -tlnp to check whether the target port is LISTEN and which process holds it.

Why Use ss Instead of netstat?

The NOTES section of the netstat man page states clearly: "This program is mostly obsolete. Replacement for netstat is ss." In other words, ss is officially positioned as its successor. Likewise, the man page says the replacement for netstat -r is ip route, and the replacement for netstat -i is ip -s link.

In practice, ss is faster than netstat; it obtains socket information directly from the kernel rather than reading /proc/net. Its option scheme is highly compatible, so netstat -tulnp translates almost directly to ss -tulnp. Old runbooks still carry netstat, but on new systems ss is the standard first choice. The correspondence (ss succeeds netstat, ip route succeeds route / netstat -r) is also a frequent LPIC-1 exam point.

Common Mistakes

• Stopping because you assume netstat: Minimal containers and newer distros may not include netstat (net-tools). Knowing ss lets you work with no extra install.
• Concluding "down" from a ping failure: In ICMP-blocking environments, ping fails even when everything is fine. Judge together with TCP port reachability (ss / application-layer checks).
• Mistaking a DNS fault for a connectivity fault: Do not conclude "the network is down" from a ping domain-name failure alone. If an IP literal (ping 8.8.8.8) works, the physical, IP, and routing layers are fine and the cause is DNS.
• Overlooking a missing default gateway: When the LAN works but you cannot get out, ip route often lacks a default via ... line. Do not stop after only checking the address.
• Misreading ss ports due to name resolution: Without -n, :22 shows as :ssh, slowing down port identification. Add -n when checking.

Troubleshooting

Symptom: ping example.com fails with Name or service not known

Cause: The network is fine, but DNS name resolution is failing

Check:

ping -c 2 8.8.8.8
dig +short example.com

Fix: If pinging the IP literal works, the physical, IP, and routing layers are fine. If dig cannot resolve, check the nameserver line in /etc/resolv.conf and set a reachable DNS server.

Symptom: The LAN works but the internet is unreachable

Cause: The default gateway is missing or wrong

Check:

ip route show
ping -c 2 192.168.1.1

Fix: Confirm ip route has a default via <gateway IP> line. If missing, add it with ip route add default via <gateway IP> (make it persistent via the distro's configuration file).

Symptom: A service is started but clients cannot connect

Cause: The process is not listening on the intended address/port, or a firewall is blocking it

Check:

ss -tlnp

Fix: Confirm the target port is LISTEN and the listen address is not 127.0.0.1 (local only) but something like 0.0.0.0. If it is LISTEN, the app is fine and the cause is likely on the firewall side.

Symptom: traceroute stalls at * * * partway through

Cause: A router along the way does not return ICMP, or the route really breaks there

Check:

traceroute 8.8.8.8
tracepath 8.8.8.8

Fix: Even with * * *, if the trace reaches the destination with a reply on the final line, the route is alive (the intermediate router just does not return ICMP). If it never reaches the final hop, you can narrow the fault to beyond the last hop that responded.

Completion Checklist

• [ ] Checked the interface and IP with ip addr / ip link
• [ ] Checked the default gateway with ip route
• [ ] Checked connectivity to the gateway and an external IP with ping -c
• [ ] Checked where the route stops with traceroute / tracepath
• [ ] Checked DNS name resolution with dig / host
• [ ] Checked listening ports and processes with ss -tulnp

Summary

The essence of network troubleshooting is "clearing layers in order". Checking from the bottom lets you reach the cause without relying on intuition. Combine this with knowing that netstat is replaced by ss and ifconfig/route by ip, and you cover the 109.3 objective end to end.

Next Reading

• Internet Protocols Fundamentals
• Basic Network Configuration
• DNS Client Configuration