Troubleshoot network issues with ss ip ping and tracepath

When a Linux host loses network access, many people jump straight to DNS or firewall rules. That usually wastes time. A better method is to test in order: local interface, local socket state, nearby network, then remote path. This article shows a practical flow with ss, ip, ping, and tracepath. The same flow works on Debian 13.3, Ubuntu 24.04.3 LTS, Ubuntu 25.10, Fedora 43, RHEL 10.1, and RHEL 9.7.

Start With a Fast Local Check

First, confirm the machine has a usable interface, address, and route. If this base state is wrong, remote tests are noise.

# 1) Is the interface up?
ip -br link

# 2) Does it have an IPv4 address?
ip -4 -br addr

# 3) Is there a default route?
ip route

# 4) Can ARP/ND resolve the gateway?
ip neigh

What you want to see:

• Interface state UP (for example ens18 UP).
• A correct address and prefix (for example 192.168.10.25/24).
• A default route (for example default via 192.168.10.1 dev ens18).
• Gateway neighbor entry in REACHABLE or STALE state, not repeated FAILED.

Production consequence: if the host has no default route after a reboot, every outbound dependency fails. You might see package update failures, backup upload failures, and health checks timing out at once.

Use ss to Confirm Local Service and Client State

ss reads kernel socket data directly and is faster than old netstat. Use it to answer two questions:

• Is my service listening on the expected port?
• Are client connections being established or stuck?

# Show listening TCP/UDP sockets with process names
ss -tulpen

# Check one service port, example HTTPS
ss -ltn '( sport = :443 )'

# View active outbound TCP sessions
ss -tan state established

# Watch retransmits and queue pressure (helpful under packet loss)
ss -ti dst 10.20.30.40

If a web service should listen on 443 but ss -ltn shows nothing, the issue is local service startup, not routing. If sockets exist but many flows sit in SYN-SENT, packets leave the host but no handshake returns. That points to gateway, firewall, security group, or upstream path issues.

Production consequence: teams sometimes restart app containers repeatedly when the real problem is upstream ACL blocking return traffic. ss helps avoid that wrong action quickly.

Use ip and ping to Split Link, Routing, and DNS Problems

ping is simple and still useful when used in steps. Test nearest target first, then farther targets.

# Step A: ping local gateway
ping -c 3 192.168.10.1

# Step B: ping known external IP (tests routing without DNS)
ping -c 3 1.1.1.1

# Step C: ping hostname (adds DNS dependency)
ping -c 3 example.com

# Optional: verify resolver response directly
getent hosts example.com

# Optional: show policy routes/rules if behavior is inconsistent
ip rule show
ip route show table main

How to read outcomes:

• Gateway ping fails: likely local VLAN, cabling, virtual switch, or host firewall problem.
• Gateway works but external IP fails: route/NAT/upstream firewall issue.
• External IP works but hostname fails: DNS resolver or search domain issue.

Do not trust one successful ping as final proof. Short packet loss bursts can still break SSH, API calls, and database replication. Run a longer sample during incidents:

# 50 probes with timestamps
ping -D -c 50 10.50.0.20

If you see occasional high latency spikes, that can explain user complaints even when monitoring says "host up".

Use tracepath for Route and MTU Discovery

tracepath helps when traffic partly works but larger transfers fail. It also reports discovered path MTU without root privileges on most systems.

# Numeric output avoids DNS delays while tracing
tracepath -n 203.0.113.25

# Example public target test
tracepath -n 1.1.1.1

Typical output includes lines like pmtu 1500 and sometimes a lower value later, for example pmtu 1450. If your source host sends 1500-byte frames while a tunnel path only supports 1450 and ICMP filtering blocks PMTU feedback, you get a PMTU black hole. Small requests may pass, but TLS handshakes, package downloads, or container image pulls stall.

In that case, test with reduced MTU on the interface or fix filtering so ICMP fragmentation-needed messages are allowed. The fix depends on who controls the path, but tracepath gives evidence for the network team.

Practical Incident Flow You Can Reuse

Example: an app server cannot reach a payment API. Use this short runbook:

# 1. Baseline host network
ip -br link
ip -4 -br addr
ip route

# 2. Validate DNS for API hostname
getent hosts api.vendor.example

# 3. Test IP reachability
ping -c 4 198.51.100.22

# 4. Test path and MTU
tracepath -n 198.51.100.22

# 5. Check TCP handshake attempts from app host
ss -tan '( dport = :443 )'

# 6. Optional live packet sample during one request
# tcpdump -ni any host 198.51.100.22 and tcp port 443

Decision points:

• No route/default route missing: fix interface profile or routing config.
• DNS fails only: fix resolver settings or DNS server path.
• Ping works but TCP handshake fails: check firewalls/ACL/stateful return path.
• Small traffic works but large traffic stalls: investigate MTU and ICMP filtering.

This process is beginner-friendly because each step answers one clear question. It is also production-safe because you collect evidence before changing configs.

Compatibility Notes for Current Distributions

• Debian 13.3: ip and ss come from iproute2. ping and tracepath are in iputils/iputils-tracepath packages depending on repository split.
• Ubuntu 24.04.3 LTS and Ubuntu 25.10: same toolset and syntax as Debian family; NetworkManager is common on desktop, netplan plus systemd-networkd is common on servers.
• Fedora 43: tools are typically preinstalled on server images; package source is iproute and iputils. Firewalld/nftables defaults can affect ping and trace behavior.
• RHEL 10.1 and RHEL 9.7: syntax is the same for all commands in this article. If tracepath is missing on minimal images, install iputils. Compatibility with RHEL 9.7 is direct for these commands.

# Install missing tools if needed
# Debian/Ubuntu
sudo apt update && sudo apt install -y iproute2 iputils-ping iputils-tracepath

# Fedora/RHEL
sudo dnf install -y iproute iputils

Summary

Troubleshooting gets faster when you follow a fixed order: local interface and routes with ip, socket truth with ss, reachability and DNS split with ping, then path and MTU detail with tracepath. This avoids random restarts, gives clear evidence, and reduces downtime during real incidents.