Linux Performance Tuning: Hands‑On Breakdown of ss, ip, tc, and ethtool for Network Troubleshooting

After covering how packets travel from an application process to the NIC, this article provides a detailed, hands‑on breakdown of the four most common Linux network‑troubleshooting commands: ss, ip, tc, and ethtool.

1. ss – the application‑layer tool

ss

reads socket information directly from the kernel, making it orders of magnitude faster than netstat, which parses /proc entries.

Check listening ports: ss -tuln If the output contains LISTEN, a service is listening (e.g., verify MySQL on port 3306).

Inspect connection states:

ss -tan state established

ss -tan state time-wait

ss -tan '( sport = :80 or dport = :80 )'

Use ss -s to view overall socket statistics and assess memory usage of TIME_WAIT connections.

Locate connection leaks: ss -tanp | grep 192.168.1.100 | wc -l Adding -p shows the owning process name and PID, helping identify applications that fail to close sockets. ss -s – view overall socket water‑level ss -tanp state established – view active connections ss -tanp state time-wait – view aging connections

2. ip – the network‑layer core

ip

is the centerpiece of the iproute2 suite, replacing the older ifconfig, route, and arp utilities.

Show addresses: ip addr show eth0 Displays IP, netmask, and broadcast address in a clear format.

Show routes: ip route show Shows default and specific routes. To see the exact path for a destination: ip route get 8.8.8.8 Outputs the egress interface, source address, and gateway.

Show ARP table: ip neigh show If a neighbor entry is FAILED or INCOMPLETE, the L2 link is broken, making further routing or iptables checks unnecessary.

Policy routing:

ip rule show

ip route show table 100

Allows fine‑grained traffic control in multi‑NIC scenarios (e.g., route 10.0.0.0/8 via eth1, external traffic via eth0).

Hidden skill – live monitoring: ip monitor Continuously prints changes to routes, addresses, and neighbors.

3. tc – the link‑layer traffic shaper

tc

operates just before packets leave the kernel for the NIC, making it the only tool that can shape egress traffic.

Show current qdisc: tc qdisc show dev eth0 The default is pfifo_fast with three priority bands, which is sufficient for most workloads.

Simulate network latency:

tc qdisc add dev eth0 root netem delay 100ms

tc qdisc del dev eth0 root

Useful for testing application behavior under weak‑network conditions.

Rate‑limit bandwidth:

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

Emulates a low‑speed link to observe system performance under bandwidth bottlenecks.

Important note: tc only controls egress. To shape ingress, one must use an ingress qdisc with an ifb virtual interface on the peer or locally.

4. ethtool – the physical‑layer inspector

ethtool

is the sole tool for examining NIC and cable health.

Check link status: ethtool eth0 Shows Speed, Duplex, Auto‑negotiation, and Link detection, which eliminates many hardware‑related issues.

Inspect driver and firmware:

ethtool -i eth0

driver: ixgbe
version: 5.15.0
firmware-version: 0x61b0d001
bus-info: 0000:03:00.0

An outdated driver can cause packet loss; upgrading resolved a real‑world incident described in the article.

View hardware statistics:

ethtool -S eth0

rx_dropped / tx_dropped

– ring buffer overflow rx_crc_errors – physical‑layer checksum errors (often cable or optics) rx_fifo_errors – FIFO overflow, interrupt handling lag

Typical packet‑loss investigation flow: ethtool -S eth0 | grep -i error – any hardware errors? ethtool -k eth0 | grep on – verify offload features (TSO, GRO) are enabled ethtool -g eth0 – check ring buffer sizes, enlarge if needed ethtool -m eth0 – examine optical module power levels

Deep‑dive private flags: ethtool --show-priv-flags eth0 Some NICs expose vendor‑specific flags, such as Mellanox's rx_steering.

Putting the four layers together

ss   – view connections → is the service reachable?
ip   – view routing    → is the path correct?
tc   – view queuing    → is traffic being limited?
ethtool – view hardware → is the NIC or cable faulty?

By confirming each layer before moving to the next, you avoid blind guessing and obtain a clear, step‑by‑step roadmap from application to physical signal.