LinuxXLII · Network PerformancePacket loss
Packet loss and retransmits - when the network drops
What you'll learn
- Detect packet loss
- Distinguish TCP retransmit causes
- Read TCP stats from /proc/net
- Diagnose and fix network problems
Prerequisites
Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09
Packet loss and TCP retransmits are the network’s “something is wrong” signal. A few percent loss can reduce throughput by 10x. This lesson covers detection and causes.
Detect packet loss
# ICMP loss
ping -c 100 server
# Check the "packet loss" line
# TCP loss
ss -ti
# retrans shows retransmits per connection
ss -ti shows TCP info for each connection, including
retransmits.
Read TCP stats
cat /proc/net/netstat | grep -E 'Tcp:|TcpExt:'
Key fields:
TcpActiveOpens: connections initiated.TcpPassiveOpens: connections accepted.TcpEstabResets: connections reset.TcpEstabResets: established connections reset.TcpInSegs: segments received.TcpOutSegs: segments sent.TcpRetransSegs: segments retransmitted.TcpInErrs: incoming errors.TcpOutRsts: resets sent.
Retransmits vs total segments gives the retransmit rate.
Read /proc/net/snmp
cat /proc/net/snmp | grep Tcp
Same fields as netstat, in a different format.
TCP retransmits
A TCP retransmit is a packet that the sender did not get an ACK for. Common causes:
- Packet loss: physical link issue, congestion, NIC driver bug.
- Path change: routes changed mid-connection.
- Buffer full: receive queue full; packets dropped.
- Duplex mismatch: half-duplex on one side, full on the other.
A few retransmits are normal. A high rate (1% or more) is a problem.
Throughput impact
TCP throughput is bounded by the bandwidth-delay product and loss rate:
throughput = (MSS / RTT) * (1 / sqrt(p))
where p is the loss probability. A 1% loss rate can halve throughput on a high-latency link.
Common causes
| Cause | Detection |
|---|---|
| Network congestion | High loss, high latency, jitter |
| Bad cable | Loss increases over time, often correlated with traffic |
| Duplex mismatch | Errors on one side, retransmits on the other |
| Switch/router buffer full | Drops under load, not at idle |
| Driver bug | dmesg for driver errors, ethtool for counters |
| Firewall drops | nft list ruleset, conntrack -L |
Diagnose
# Path-level: traceroute
traceroute server
# Interface errors
ip -s link show eth0
ip -s -s -s link show eth0 # more detail
# NIC errors
ethtool -S eth0 | grep -E 'err|drop|missed'
# TCP-level
ss -tinpe
# Connection-specific
ss -ti dst :443
For UDP packet loss:
# iperf3 UDP test
iperf3 -c server -u -b 1G
# Loss shown in output
Fix
- Bad cable: replace.
- Duplex mismatch: force both sides to the same setting
(
ethtool -s eth0 autoneg off speed 1000 duplex full). - Switch buffer full: enable ECN, increase buffer.
- Network congestion: reduce traffic, increase capacity.
- Driver bug: update kernel or NIC driver.
Knowledge check
Knowledge check · 3 questions
Q1. What does a high TCP retransmit rate indicate?
Q2. TCP throughput falls with the square root of the loss rate, so a long-RTT link degrades sharply at 1% loss.
Q3. Which of the following can cause packet loss? Select all that apply.
Passing score: 75%. Answers are checked in this browser.