NODELOG by THIVELAB
Subscribe
Home/Engineer/Troubleshooting/Diagnosing Network Packet Lo…
TroubleshootingIntermediateUbuntuDebianCentOSpingmtrtcpdump

Diagnosing Network Packet Loss — ping · mtr · tcpdump

How to confirm packet loss with ping, locate the hop where it occurs with mtr, and capture live packets with tcpdump to analyze retransmissions and errors.

NONodelog0 views
Contents
  1. Step 1 — Check basic loss with ping
  2. Step 2 — Find the hop where loss occurs with mtr
  3. Step 3 — Analyze packets with tcpdump
  4. Step 4 — Check TCP retransmission stats
  5. Step 5 — Fixes by cause

Step 1 — Check basic loss with ping

Bash
# Basic ping (stop with Ctrl+C, then check stats)
ping 8.8.8.8

# Send 100 packets, then show stats
ping -c 100 8.8.8.8

# Fast ping (0.2s interval)
ping -i 0.2 -c 200 8.8.8.8

# Interpreting results
# packet loss = 0%: healthy
# packet loss = 1~5%: minor loss
# packet loss > 10%: serious problem

# Check MTU issues with large packets
ping -s 1400 -M do 8.8.8.8   # Don't fragment
ping -s 1472 -M do gateway_ip  # Probe maximum MTU

Step 2 — Find the hop where loss occurs with mtr

Bash
sudo apt install -y mtr-tiny

# Interactive mode
mtr 8.8.8.8

# Report after 100 packets
mtr --report --report-cycles 100 8.8.8.8

# TCP mode (when ICMP is blocked)
mtr --tcp --port 443 example.com

Interpreting mtr results

CODE
                             Loss%   Snt   Avg  Best  Wrst StDev
1. 192.168.1.1 (gateway)      0.0%   100   1.2   0.8   5.1   0.6
2. 100.64.0.1  (ISP)         0.0%   100  10.5   9.8  25.3   2.1
3. 203.0.113.1 (intermediate hop) 5.0% 100 18.3 17.1 89.5 12.4  ← loss starts here
4. 203.0.113.2               5.0%   100  20.1  19.0  92.3  13.2
5. 8.8.8.8    (destination)   5.0%   100  22.4  21.0  95.0  13.8
  • Loss starts at hop 3 → the problem is on the hop-3 segment
  • High loss only on an intermediate hop, destination at 0% → that router is rate-limiting ICMP (normal)

Step 3 — Analyze packets with tcpdump

Bash
# List interfaces
sudo tcpdump -D

# Filter by interface and host
sudo tcpdump -i eth0 host 8.8.8.8

# Port filter
sudo tcpdump -i eth0 tcp port 443

# Print packet contents (-A: ASCII, -X: Hex+ASCII)
sudo tcpdump -i eth0 -A tcp port 80 | head -50

# Save to file (for Wireshark analysis)
sudo tcpdump -i eth0 -w capture.pcap tcp port 443

# Read a saved file
sudo tcpdump -r capture.pcap

# Filter TCP retransmission packets
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

Step 4 — Check TCP retransmission stats

Bash
# Socket stats with ss
ss -s

# TCP retransmission counters
cat /proc/net/snmp | grep Tcp
# If RetransSegs keeps climbing, retransmissions are in progress

# Check with netstat
netstat -s | grep -i retransmit

# Track counters with nstat
nstat | grep Retran

Step 5 — Fixes by cause

Loss on the ISP path

Bash
# ISP-side issue — collect evidence before contacting support
mtr --report --report-cycles 200 8.8.8.8 > mtr_report.txt
traceroute -n 8.8.8.8

Server interface errors

Bash
# Check error counters
ip -s link show eth0
# Inspect the errors and dropped fields

# Driver errors
dmesg | grep -i "eth0|network|link"

# Restart the interface
sudo ip link set eth0 down && sleep 1 && sudo ip link set eth0 up

MTU mismatch

Bash
# Check MTU
ip link show eth0 | grep mtu

# Change MTU (often needed on VPN)
sudo ip link set eth0 mtu 1450

Buffer tuning

Bash
# Increase network buffer sizes
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 134217728'
sudo sysctl -w net.ipv4.tcp_wmem='4096 65536 134217728'
#ping#mtr#tcpdump#Troubleshooting
Editorial note

AI tools may assist drafting. Check the evidence in each guide for whether commands were run and which environment was used. Confirm the current docs for your version before applying instructions, and email us about errors. email us

How we write and review →Editorial policy →

Questions & answers

Ask a question about this guide. We'll review and reply.