Inspecting Networks with ip, ss, ping, and traceroute

1. Diagnose from local state outward

A useful network investigation is ordered. Confirm the process and destination, verify local link state and counters, inspect addresses, ask the kernel which route and source it would use, inspect neighbor state, test the local gateway, test a destination by address, then test name resolution and application protocol behavior. Random commands produce noise; a layered sequence narrows the fault domain.

flowchart TB
  A["1. Interface and counters"] --> B["2. Address and prefix"]
  B --> C["3. Route and source selection"]
  C --> D["4. Neighbor and gateway"]
  D --> E["5. Remote IP reachability"]
  E --> F["6. DNS resolution"]
  F --> G["7. Port, TLS, and application protocol"]
  G --> H["Preserve evidence and compare"]

2. ip exposes the kernel network model

The ip suite is organized by objects: link, address, route, rule, neighbor, and more. Prefer concise output for inventory and detailed output for diagnosis. Counters help separate configuration errors from physical or driver problems: rising receive errors, drops, overruns, or carrier changes point below the application layer.

ip -brief link
ip -brief address
ip -statistics link
ip route show
ip -6 route show
ip rule show
ip neighbor show

# Let the kernel explain route and selected source
ip route get 8.8.8.8

# Continuous event stream; press Ctrl+C to stop
# ip monitor link address route neighbor

ip route get is especially valuable because it performs route lookup without sending a packet. It can reveal an unexpected source address, table, output interface, or gateway before any reachability test.

3. ss answers which sockets exist and who owns them

ss reads kernel socket information and replaces many traditional netstat workflows. Listening sockets establish which local services accept connections. Established and transitional states show active sessions and connection lifecycle. Process information usually requires sufficient permission.

# Summary by protocol and state
ss -s

# Listening TCP and UDP sockets, numeric addresses
ss -lntup

# Established TCP sessions
ss -tn state established

# Filter by source or destination port
ss -lnt 'sport = :22'
ss -tn 'dport = :443'

# Include timers and extended TCP details
ss -tnoi

4. ping tests ICMP echo, not “the network”

Ping can confirm round-trip IP reachability and measure latency variation when echo request and reply are permitted. Some hosts and firewalls intentionally drop or rate-limit ICMP while allowing application traffic. Therefore a failed ping is evidence, not proof that the destination is unavailable.

# Bound the test: count, timeout, and numeric output
ping -n -c 4 -W 2 127.0.0.1

# Test the selected default gateway when one exists
gateway=$(ip route show default | awk 'NR==1 {print $3}')
[ -n "$gateway" ] && ping -n -c 4 -W 2 "$gateway"

# Force IPv4 or IPv6
ping -4 -n -c 4 -W 2 example.com
ping -6 -n -c 4 -W 2 example.com 2>/dev/null || true

Interpret loss, latency, and variation in context. Wireless power saving, ICMP rate limiting, asymmetric paths, virtualized scheduling, and queueing can affect results. Compare against a baseline and the application’s actual protocol.

5. Traceroute infers path hops through TTL or hop-limit expiry

Traceroute sends probes with increasing TTL values. Routers that reduce TTL to zero may return ICMP time-exceeded messages, allowing the tool to infer hops. Different implementations use UDP, ICMP, or TCP probes; firewalls and equal-cost multipath routing can produce different paths or missing responses.

# Numeric output avoids DNS delays during path diagnosis
traceroute -n -m 15 -w 2 1.1.1.1 2>/dev/null || true

# ICMP probes, where supported
traceroute -I -n -m 15 1.1.1.1 2>/dev/null || true

# TCP probes can resemble application traffic
traceroute -T -p 443 -n -m 15 example.com 2>/dev/null || true

# tracepath often works without elevated privileges
tracepath -n 1.1.1.1 2>/dev/null || true

6. Hands-on lab: create a layered diagnostic report

lab="$HOME/devops-academy/linux/chapter12/lesson02"
mkdir -p "$lab"
cd "$lab"

{
  date --iso-8601=seconds
  printf '\n=== links ===\n'; ip -brief link
  printf '\n=== addresses ===\n'; ip -brief address
  printf '\n=== routes ===\n'; ip route show
  printf '\n=== route lookup ===\n'; ip route get 1.1.1.1 2>&1 || true
  printf '\n=== neighbors ===\n'; ip neighbor show
  printf '\n=== socket summary ===\n'; ss -s
  printf '\n=== listeners ===\n'; ss -lntup 2>&1 || true
} > local-state.txt

ping -n -c 4 -W 2 127.0.0.1 > ping-loopback.txt 2>&1 || true
ping -n -c 4 -W 2 1.1.1.1 > ping-remote.txt 2>&1 || true
traceroute -n -m 12 -w 2 1.1.1.1 > path.txt 2>&1 || true
sha256sum ./*.txt > evidence.sha256

7. Common diagnostic mistakes

8. Knowledge check

9. Summary

Modern Linux network diagnosis combines ip for kernel state, ss for sockets, bounded ping tests for ICMP evidence, and traceroute or tracepath for path inference. The value comes from ordering tests, preserving timestamps and outputs, and refusing to treat one tool as a verdict on the whole network.

10. Further reading

• ip(8), ip-monitor(8), and ss(8).
• ping(8), traceroute(8), and tracepath(8).
• Kernel networking statistics documentation and distribution troubleshooting guides.