Network diagnostics in Linux

Q: ping by IP works, ping by name doesn't

The network is fine, DNS isn't working. See dns-resolv: resolvectl status, getent hosts name, dig @8.8.8.8 name.

Q: Not even the gateway pings

A local problem: no address/route (ip -br a, ip r), the link is down, the wrong VLAN/subnet, a duplicate IP. Check ip and netplan.

Q: Loss/high latency in the middle of the path

mtr -rwc 20 shows which hop the loss grows at. Loss only at an intermediate hop but not at the destination is usually normal (routers deprioritize ICMP addressed to themselves). Loss that persists to the end is a real problem with the link.

Q: ICMP is blocked — ping isn't meaningful

Many hosts don't answer ping on purpose. Check port reachability with nc and trace with traceroute -T -p 443, instead of relying only on ICMP.

Q: "It works some of the time"

Intermittent loss: run ping -c100 -i0.2, mtr for longer. Often a congested link, a duplicate IP on the network, or a flapping link.

Overview

"The network doesn't work" is vague. Diagnose it by walking a ladder of layers, ruling out half the possibilities at each step:

is there an address? → ip -br a
is the gateway reachable? → ping gateway
is there internet (L3)? → ping 8.8.8.8
does DNS work? → getent hosts name (see dns-resolv)
is the destination port reachable? → nc -zv host port

Each step answers "how far did it get" and cuts the search space in half.

Recipes

2

ping

bash

ping -c4 192.168.1.1             # 4 packets and stop (otherwise it runs forever)
ping -c4 8.8.8.8                 # internet connectivity by IP
ping -c4 -W1 host                # 1s response timeout (don't wait long)
ping -c100 -i0.2 host            # more frequent (0.2s) — catch rare drops
ping -s1472 -Mdo -c3 host        # check MTU/fragmentation (1472+28=1500)
ping6 -c4 2001:4860:4860::8888   # IPv6

In the output, look at: loss (packet loss) and spread (rtt min/avg/max). 0% and a stable rtt mean the link is healthy.

traceroute / mtr

bash

traceroute 8.8.8.8               # the packet path, hop by hop (where it's lost)
traceroute -n 8.8.8.8            # without DNS (faster)
traceroute -T -p 443 host        # a TCP trace to port 443 (when ICMP is blocked)
mtr 8.8.8.8                      # traceroute + ping, live (the best of both)
mtr -rwc 10 example.com          # a 10-cycle report (for tickets/messages)
mtr -T -P 443 host               # mtr over a TCP port
ip route get 8.8.8.8             # which route/interface it will actually take

mtr is the main tool: it shows loss at every hop, so you can see exactly whose segment is dropping packets (yours, your provider's, or an intermediate node's).

Troubleshooting

6

ping by IP works, ping by name doesn't

The network is fine, DNS isn't working. See dns-resolv: resolvectl status, getent hosts name, dig @8.8.8.8 name.

Not even the gateway pings

A local problem: no address/route (ip -br a, ip r), the link is down, the wrong VLAN/subnet, a duplicate IP. Check ip and netplan.

Ping works, but the service is unreachable

ICMP gets through, but the port doesn't. Check the port: nc -zv host port. Next, check that the service is listening (ss) and firewall.

Loss/high latency in the middle of the path

mtr -rwc 20 shows which hop the loss grows at. Loss only at an intermediate hop but not at the destination is usually normal (routers deprioritize ICMP addressed to themselves). Loss that persists to the end is a real problem with the link.

ICMP is blocked — ping isn't meaningful

Many hosts don't answer ping on purpose. Check port reachability with nc and trace with traceroute -T -p 443, instead of relying only on ICMP.

"It works some of the time"

Intermittent loss: run ping -c100 -i0.2, mtr for longer. Often a congested link, a duplicate IP on the network, or a flapping link.

Terms

2

ICMP: An IP control-message protocol; ping uses echo requests and replies. Also appears in: ping, Firewall, Capabilities: root split into parts, nmap: which ports are visible from outside and 1 more
end-to-end check: A test of the required operation from its client through the expected service response.

Network diagnostics

Cheat sheet