Print | Rate this content

Red Hat Enterprise Linux 5 & 6 (x86-64) - What are udp "packet receive errors" and "packets to unknown port received"

Title: Red Hat Enterprise Linux 5 & 6 (x86-64) - What are udp "packet receive errors" and "packets to unknown port received"
Object Name: mmr_kc-0102153
Document Type: Support Information
Original owner: KCS - Linux
Disclosure level: Public
Version state: final
Environment
FACT:Red Hat Enterprise Linux 6 (x86-64)
FACT:Red Hat Enterprise Linux 5 (x86-64)
Questions/Symptoms
GOAL:To understand and attempt to resolve udp errors seen in netstat -su.
SYMPTOM:Example: netstat -su partial output.

Udp:
    79258313 packets received
    208531 packets to unknown port received.   <<<<
    1536 packet receive errors                 <<<<
    85514 packets sent
Cause
CAUSE:A lot of this text is from an elevation regarding this issue:

1.  The errors reported as UDP packet receive errors originate from kernel counter UDP_MIB_INERRORS and this counter is increased in two cases:    
- corrupted packets (incorrect headers or checksum)  
- full RCV buffer size

Additionally, UDP protocol does not have built-in flow-control (like TCP does). This  means that if an application is reading packets slower than they arrive, sooner or later the system will start discarding them. TCP in this case closes the window, which says to sender stop sending, but there is nothing like that in UDP.  

2. The errors reported as packets to unknown port received are from kernel counter UDP_MIB_NOPORTS and mean that there is no socket for this port - i.e. The user gets some packets and did not expect. These are receive packets that were dropped by the kernel. This can happen when an application fails to read from the receive buffer fast enough. 

The message indicates something is sending udp packets to the system, for which there is no receiving port open or available. The most probable explanation is as UDP services are connectionless, it is possible that when you stop a service or an application using UDP, the other side still sends some packets until it realizes that nobody is listening to them - this is normal and should not create any problems, but these packets will be to unknown port. 

Neither of these errors are from the NIC driver level. They are from the udp protocol level. However, sometimes if an application buffer fills, the driver's buffer may then also start to fill. To also check for NIC/driver errors, check these outputs:

# ifconfig <interface>  
Look at the line starting with "RX packets"

# ethtool -S <interface>
Review lines starting with "rx"
Answer/Solution
FIX:The percentage of errors to the total number of udp packets received may be low enough to be negligible to the application. If the errors do seem to be impacting the application, consider tuning udp, offloading udp traffic, and tuning the application.

1. Consider increasing these parameters in the 
/etc/sysctl.conf file according to the current settings and system memory. Refer to the following file for more information, if the kernel-doc package is installed.
/usr/share/doc/kernel-doc-<vers>/Documentation/networking/
ip-sysctl.txt

net.core.rmem_default <bytes>  
net.core.rmem_max <bytes>  
net.ipv4.udp_mem <min pages> <pressure pages> <max pages> 
net.ipv4.udp_rmem_min <bytes>

2. Enable UDP fragmentation offload on all NICs involved.  
# ethtool -K eth? ufo on  

Turn off checksumming.    
# ethtool -K eth? rx off  
# ethtool -K eth? tx off   

Add these options to the ETHTOOL_OPTS parameter in the 
/etc/sysconfig/network-scripts/ifcfg-eth? files.  Refer to the following Red Hat article for syntax on this option.

https://access.redhat.com/knowledge/solutions/54229

3. Review the /var/log/messages file, or analyze tcpdump output to see if there is any udp traffic that could be eliminated. For example, in this case we saw snmpd logging an extreme amount of messages. The user decreased the logging level, and elminated a lot of traffic.

# grep UDP messages* | grep snmpd | wc -l
27968

If this issue is seen, first stop snmpd.
# service snmpd stop 

To lower logging level, in /etc/sysconfig/snmpd, uncomment and edit the OPTIONS line. Change the -L flag file to one of the following, and restart snmpd.

-Lsw (warning and above)    
Or    
-Lsc (critical and above) 

# service snmpd start

4. If the issue is occurring on a VMware guest, check for any updates to the vm network driver in use.

5. Work with the application vendor and ask for any tuning options like increasing application receive buffer sizes, number of daemons running, or anything that could aid in getting the information out of the buffers faster.  Check for any other possible bottlenecks, like does the application writes the buffered data to a slow filesystem or disk.  

6. If RX errors are also seen in the ifconfig or ethtool output, there may be driver level tuning options. Review the appropriate driver documentation for tuning options.

© Copyright 2014 Hewlett-Packard Development Company, L.P.

Legal Disclaimer: Products sold prior to the November 1, 2015 separation of Hewlett-Packard Company into Hewlett Packard Enterprise Company and HP Inc. may have older product names and model numbers that differ from current models.

Provide feedback

Please rate the information on this page to help us improve our content. Thank you!
Document title: Red Hat Enterprise Linux 5 & 6 (x86-64) - What are udp "packet receive errors" and "packets to unknown port received"
Document ID: mmr_kc-0102153-8
How helpful was this document?
How can we improve this document?
Note: Only English language comments can be accepted at this time.
Please wait while we process your request.