Packet receive errors

A packet error means there’s something wrong with the packet. There are two types of packet errors that usually occur:

• Transmission errors, where a packet is damaged on its way to its destination—like a fragile Amazon order that gets dinged up en route.
• Format errors, where a packet’s format isn’t what the receiving device was expecting (or wanting). Think ordering a Coca-Cola in a restaurant and getting a Pepsi instead.

A packet discard happens when a received packet has a transmission or format error, or when the receiving device doesn’t have enough storage room for it.

Packet loss happens before a packet reaches its destination, which means it can happen anywhere in a network.

Issue

• netstat -s output shows high number of Udp: packet receive errors
• Getting high number of UDP packet drops or loss
• SNMP trap issue :- SNMP trap seems to be fluctuating on my RHEL server.

Most common types of events that cause these errors are

• incorrect length of VLAN tag
• unexpected VLAN tag
• unsupported L2 protocol
• incorrect IP checksum
• TCP/UDP packet checksum error
• TCP/UDP port 0
• Invalid TCP flag, etc.

Very often, a constant increase of this counter is caused by STP/LLDP/UDLD frames arriving on a L3 firewall port (these protocols are not supported on L3 ports and are legitimately dropped and counted as “Receive errors”).

For the above output, look at the following information to see how UDP packet loss is occurring.

• packet receive errors is not empty and keeps growing indicating that the system has UDP packet loss
• packets to unknown port received indicates that the target port where the UDP message was received is not being listened to, which is usually caused by the service not being started and does not cause serious problems
• receive buffer errors indicates the number of packets lost because the UDP receive buffer is too small

To get more information on the issue take a look atUsing the pktcap-uw tool in ESXi 5.5 and later (2051814) | VMware KB​ . It would help if you have the exact Packet Receive Errors. Have you looked through the host logs or esxtop for any obvious issues?

Those grok patterns with multiple occurrences for %{DATA} are going to be really, really expensive if they do not match. It has to look for the timestamp starting at every character in the message, then once it matches that it has to check for the IP at every following character and so on.

Break up your patterns.

You can try that, but you may have better luck looking for errors in your server event logs that correspond with the packet errors.