How to Diagnose and Fix UDP Packet Loss on Linux Servers
Learn step-by-step how to verify UDP packet loss on Linux, interpret driver and kernel statistics, adjust ring buffers and socket buffers, and use tools like ethtool, netstat, dropwatch, and perf to pinpoint and resolve network drops caused by hardware, configuration, or system load.
When encountering UDP packet loss on a Linux server, start by understanding the packet‑reception path: the NIC receives frames, the driver copies them via DMA into a ring buffer, the kernel processes the packets (IP and UDP layers) and places them into the application’s socket buffer.
Physical network cable delivers frames to the NIC.
The network driver reads frames into a ring buffer using DMA, without CPU involvement.
The kernel pulls packets from the ring buffer, runs IP/UDP logic, and queues them to the socket buffer.
The application reads packets from the socket buffer.
Any of these stages can drop packets, so loss may occur in the NIC, driver, kernel, or application.
Confirm UDP Packet Loss
Check NIC statistics with
ethtool -S eth0and look for non‑zero
bador
dropcounters; increasing values indicate NIC loss.
Another source is
ifconfig, which shows RX/TX counters.
System‑wide UDP statistics can be viewed with
netstat -s --udp. Pay attention to fields such as “packet receive errors”, “packets to unknown port received”, and “receive buffer errors”.
Note: A small non‑zero loss rate is normal for UDP; only significant loss warrants investigation.
NIC or Driver Loss
If
ethtool -S eth0shows
rx_***_errors, the NIC hardware or driver is likely at fault and should be inspected or replaced.
The command
netstat -ialso reports per‑interface errors and drops; values should be zero under normal conditions.
If the hardware is fine, a too‑small ring buffer may cause loss. View the current size with
ethtool -gand increase it, e.g.,
ethtool -G eth0 rx 8192.
Linux System Loss
Common causes inside the OS include UDP packet errors, firewall drops, insufficient UDP buffer sizes, and excessive system load.
UDP Packet Errors
Corrupted packets (checksum or length errors) are discarded by the kernel. To receive checksum errors in the application, disable UDP checksum verification via socket options.
Firewall
A misconfigured firewall can drop all or part of the UDP traffic; verify that no rules are unintentionally discarding packets.
UDP Buffer Size Insufficient
The kernel’s receive buffers are limited by
/proc/sys/net/core/rmem_max(max) and
rmem_default(default). Increase them with
sysctl -w net.core.rmem_max=26214400(25 MiB) or by editing
/etc/sysctl.conf. Similarly, the send buffers are controlled by
wmem_maxand
wmem_default.
/proc/sys/net/core/rmem_max – maximum receive buffer
/proc/sys/net/core/rmem_default – default receive buffer
/proc/sys/net/core/wmem_max – maximum send buffer
/proc/sys/net/core/wmem_default – default send buffer
For high‑throughput UDP workloads, also raise
net.core.netdev_max_backlog(default 1000) to a larger value, e.g., 2000:
sudo sysctl -w net.core.netdev_max_backlog=2000System Load Too High
CPU, memory, or I/O saturation can prevent the kernel from processing packets promptly, leading to drops at the NIC, driver, or socket buffer level. Identify and mitigate the offending load or scale resources.
Application Loss
Each application must set its own socket receive buffer size; for example, the following code configures a 20 MiB buffer:
<code>uint64_t receive_buf_size = 20*1024*1024; // 20 MB
setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));</code>If the application cannot be recompiled, look for configuration options that adjust the buffer, or request changes from the developers. Larger buffers reduce loss but increase memory usage, and processing should be asynchronous to avoid blocking the receive path.
Where Packets Are Dropped
Use
dropwatchto trace the kernel functions that discard packets:
Alternatively, the
perftool can monitor the
kfree_skbevent, which is invoked when a packet is freed:
Summary
UDP is connectionless and tolerates occasional loss; use TCP for loss‑intolerant applications.
When loss occurs, first check system load; high load often explains drops.
If load is normal, examine NIC statistics, ring buffer sizes, and kernel buffers.
Increase system and socket buffer sizes to accommodate high‑volume UDP traffic.
Process UDP packets asynchronously and avoid heavy work between receives.
References
Pivotal: Network troubleshooting guide – https://discuss.pivotal.io/hc/en-us/articles/218765528-Network-troubleshooting-guide
What are udp “packet receive errors” and “packets to unknown port received” – https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0102153
Lost multicast packets troubleshooting guide – https://ref.onixs.biz/lost-multicast-packets-troubleshooting.html
Splunk Answers: UDP Drops on Linux – https://answers.splunk.com/answers/7001/udp-drops-on-linux.html
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.