What you will achieve

A structured troubleshooting flow using ping, ss, traceroute, and ip — from "no route" to "service not listening".

1) Link and IP layer

ip -br link
ip -br addr
ip route

No IP on the interface? Check DHCP, netplan, or NetworkManager next.

2) Reachability

ping -c4 1.1.1.1
ping -c4 google.com

IP works but names fail → DNS issue. Neither works → gateway or upstream.

3) Path and latency

traceroute -4 8.8.8.8
mtr -rwzbc100 8.8.8.8

4) Listening services

sudo ss -tulpn
sudo ss -tn state established

Prefer ss over legacy netstat. If the port is closed locally, the problem is not the firewall — it is the daemon.

5) DNS

resolvectl query example.com
dig +short A example.com @1.1.1.1

Verify

Document which layer failed (L2 link, L3 IP, L4 port, L7 app) before changing configs at random.

6) ARP and local LAN issues

ip neigh show
arping -I eth0 192.168.1.1

Ping gateway fails but internet IP works — switch or cable fault on LAN segment.

7) MTU black holes

ping -M do -s 1472 8.8.8.8

If large packets fail but small succeed, lower MTU on VPN or PPPoE interfaces (mtu 1400 in netplan or NM).

8) Capture packets

sudo tcpdump -i eth0 host 8.8.8.8 and port 443 -c 20

Structured workflow

Physical link up? (ip link)
IP assigned? (ip addr)
Default route? (ip route)
Gateway reachable? (ping gateway)
DNS resolves? (dig)
Remote port open? (nc -zv host 443)
Application healthy? (curl, service logs)

9) Socket statistics by process

sudo ss -tpn | grep ESTAB

Prerequisites

Local shell access, known-good remote target (1.1.1.1, internal gateway), and optional second machine to compare behaviour. Install traceroute, dnsutils, iproute2 if minimal image lacks them.

Document baseline

When healthy, save output of ip route, resolvectl status, and ss -tulpn — compare during incidents to spot drift quickly.

nc port probe

nc -zv example.com 443
nc -zvu dns.google 53

TCP vs UDP tests isolate firewall protocol blocks.

Intermittent packet loss

Use mtr --report-wide target over 100 cycles overnight — flaky Wi‑Fi or bad switch port shows loss at consistent hop. Compare copper vs fibre paths. On bonded interfaces, verify both slaves up with cat /proc/net/bonding/bond0. Document MTU end-to-end when VPN involved — classic MSS clamp missing causes HTTPS hangs on large pages only.