Skip to main content
Back to Category

Network Packet Loss: Diagnosis and Resolution

Guide to diagnosing and resolving network packet loss using ping, traceroute, mtr, tcpdump tools, MTU issues, and network performance optimization.

Read time: 13 min Troubleshooting
pingtraceroutemtrtcpdumppacket lossnetworknetworking
Author
REXE Teknoloji Network & Security Team
Editor
REXE Teknoloji Technical Editorial
First published
Last updated

Introduction

Network packet loss is a serious issue that directly affects server performance and user experience. Packet loss can cause slow website loading, SSH connection drops, lag on game servers, and degraded VoIP quality.

In this guide, we'll examine the tools and methods you can use to detect packet loss, find its source, and resolve it.

What is Packet Loss?

Packet loss occurs when data packets sent over the network fail to reach their destination. Under normal conditions, 0% packet loss is expected. 1-2% is noticeable, and above 5% causes serious problems.

Packet LossImpact
0%Normal — no issues
1-2%Mild — noticeable in VoIP and games
3-5%Moderate — web pages slow down
5-10%Severe — connection drops begin
10%+Critical — service unusable

Detecting Packet Loss with ping

Basic Usage

hljs bash
# Simple ping test
ping -c 100 TARGET_IP

# Test with specific packet size
ping -c 50 -s 1400 TARGET_IP

# Fast ping (flood — requires root)
sudo ping -f -c 1000 TARGET_IP

# Ping with timeout setting
ping -c 100 -W 2 TARGET_IP

Output interpretation:

100 packets transmitted, 97 received, 3% packet loss, time 99145ms
rtt min/avg/max/mdev = 1.234/5.678/45.123/8.901 ms
  • 3% packet loss: 3 out of 100 packets were lost
  • rtt avg: Average latency
  • mdev: Latency variance (jitter)

Some servers may block ICMP packets. No ping response doesn't always mean packet loss. Verify with TCP-based tests.

Continuous Monitoring

hljs bash
# Continuous ping with logging
ping TARGET_IP | while read line; do
  echo "$(date '+%Y-%m-%d %H:%M:%S') $line"
done | tee ping_log.txt

Hop Analysis with traceroute

traceroute shows every network node (hop) packets pass through to reach the destination:

hljs bash
# Basic traceroute
traceroute TARGET_IP

# ICMP-based (requires root)
sudo traceroute -I TARGET_IP

# TCP-based (port 80)
sudo traceroute -T -p 80 TARGET_IP

# Maximum hop count
traceroute -m 30 TARGET_IP

Output interpretation:

 1  gateway (192.168.1.1)  1.234 ms  1.456 ms  1.678 ms
 2  isp-router (10.0.0.1)  5.123 ms  5.456 ms  5.789 ms
 3  * * *
 4  core-router (203.0.113.1)  15.123 ms  15.456 ms  15.789 ms
 5  TARGET_IP  20.123 ms  20.456 ms  20.789 ms
  • * * *: This hop doesn't respond to ICMP (may be blocked)
  • Hops with latency spikes may be the source of the problem

Continuous Monitoring with mtr

mtr is a powerful tool that combines ping and traceroute:

hljs bash
# Installation
sudo apt install mtr -y

# Interactive mode
mtr TARGET_IP

# Report mode (100 packets)
mtr -r -c 100 TARGET_IP

# TCP mode
mtr -T -P 80 TARGET_IP

# Wide output (IP and hostname)
mtr -r -c 100 -w TARGET_IP

Reading mtr output:

HOST                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gateway              0.0%   100    1.2   1.3   0.8   5.4   0.6
2. isp-router           2.0%   100    5.4   6.1   4.2  25.3   3.2
3. core-router          0.0%   100   15.2  15.8  14.1  22.4   1.5
4. TARGET_IP            0.0%   100   20.1  20.5  19.2  28.7   1.8

Key columns:

  • Loss%: Packet loss percentage
  • Avg: Average latency
  • StDev: Standard deviation (jitter indicator)

If packet loss appears only at one hop and doesn't continue to subsequent hops, that hop may just be doing ICMP rate limiting. The real issue is when loss continues to the final hop.

Packet Capture with tcpdump

hljs bash
# Capture all traffic on an interface
sudo tcpdump -i eth0 -c 100

# Capture traffic to a specific IP
sudo tcpdump -i eth0 host TARGET_IP -c 100

# Specific port traffic
sudo tcpdump -i eth0 port 80 -c 50

# Save to file (for Wireshark analysis)
sudo tcpdump -i eth0 -w capture.pcap -c 1000

# Capture ICMP packets
sudo tcpdump -i eth0 icmp -c 50

# Capture SYN packets (for connection issues)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -c 50

Network Interface Error Check

hljs bash
# Interface statistics
ip -s link show eth0

# Detailed error counters
ethtool -S eth0 | grep -i error

# Dropped packet count
netstat -i

# Kernel network statistics
cat /proc/net/dev

# NIC ring buffer size
ethtool -g eth0

Key metrics:

  • RX errors: Received erroneous packets
  • TX errors: Transmission errors
  • RX dropped: Dropped incoming packets
  • TX dropped: Dropped outgoing packets
  • overruns: Buffer overflow

MTU Issues

MTU (Maximum Transmission Unit) mismatch can cause packet loss:

hljs bash
# Check current MTU value
ip link show eth0 | grep mtu

# MTU path discovery test
ping -c 5 -M do -s 1472 TARGET_IP

# Change MTU value (temporary)
sudo ip link set eth0 mtu 1400

Standard Ethernet MTU is 1500 bytes. If you're using VPN or tunnels, you may need to lower the MTU (typically 1400-1420).

Bandwidth Test

hljs bash
# iperf3 installation
sudo apt install iperf3 -y

# Start in server mode
iperf3 -s

# Test as client (from another server)
iperf3 -c SERVER_IP -t 30

# UDP test (packet loss measurement)
iperf3 -c SERVER_IP -u -b 100M -t 30

# Bidirectional test
iperf3 -c SERVER_IP -d -t 30

Resolution Steps

1. Identify the Source

hljs bash
# Hop-by-hop analysis with mtr
mtr -r -c 200 TARGET_IP

# Is the problem local, at ISP, or at destination?
# - Loss at first hops → Local network issue
# - Loss at middle hops → ISP issue
# - Loss at last hop → Destination server issue

2. Local Network Issues

hljs bash
# Restart network interface
sudo ip link set eth0 down && sudo ip link set eth0 up

# DNS resolution check
dig google.com +short

# ARP table check
arp -a

# Routing table check
ip route show

Conclusion

Network packet loss can stem from many different causes. Using ping, traceroute, mtr, and tcpdump, you can identify the source of the problem and apply the appropriate solution. Regular network monitoring to detect issues early is the most effective way to minimize outages.

Frequently Asked Questions

What is an acceptable packet loss rate?

Ideally it should be 0%. 1-2% is acceptable for most applications but noticeable in VoIP and game servers. Above 5% causes serious issues and requires immediate attention.

ping works but the website won't load, why?

ping uses ICMP protocol while websites use TCP. The firewall may allow ICMP but block TCP ports. Test TCP connection with telnet TARGET_IP 80 or curl.

mtr report shows 100% loss at one hop but the site works?

Some routers don't respond to ICMP packets or apply rate limiting. What matters is the packet loss at the final hop (destination). Loss at intermediate hops may be due to that hop blocking ICMP.

Packet loss only occurs at certain hours, why?

Network traffic increases during peak hours and bandwidth may become insufficient. There may be congestion at your ISP's peering points. Take mtr reports at different times and share them with your ISP.

Packet loss increases when using VPN, what should I do?

VPN overhead can cause MTU issues. Lower the MTU to 1400 on the VPN connection. Also try changing the VPN server location or using a different VPN protocol like WireGuard.

Related Articles

SSH Connection Problem: Can't Connect to Server

SSH connection troubleshooting guide: Path.net firewall rules, Default Block, creating a filter rule for SSH port, and step-by-step troubleshooting.

8 min
sshconnection problemtroubleshooting
Network TrafficInbound— GbpsOutbound— Gbps