Operations 13 min read

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.

Efficient Ops
Efficient Ops
Efficient Ops
How to Diagnose and Fix UDP Packet Loss on Linux Servers

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 eth0

and look for non‑zero

bad

or

drop

counters; 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 eth0

shows

rx_***_errors

, the NIC hardware or driver is likely at fault and should be inspected or replaced.

The command

netstat -i

also 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 -g

and 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_max

and

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=2000

System 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, &amp;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

dropwatch

to trace the kernel functions that discard packets:

Alternatively, the

perf

tool can monitor the

kfree_skb

event, 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

Network TroubleshootingLinuxsysctlUDPethtoolpacket loss
Efficient Ops
Written by

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.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.