Home / server / Questions / 528290
In Process
Fox
Asked: 2013-08-03 07:44:02 +0800 CST

ifconfig eth0 RX dropped packets

  • 772

The problem

The ifconfig command shows more and more dropped packets in the RX section. So, there seem to be a problem to some packets arriving from the Internet to my server.

The questions

  1. What kind of packets does this drop counter takes into account? Does it take all packets arriving, before reaching the iptables firewall, or after the packets have been accepted by iptables?

  2. How to solve the situation so that the ipconfig drop packets counter stops to increase?

Useful troubleshooting infos

Since I don't know what my problem really is, feel free to ask me to complete this section if you think some other info would be needed.

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:cc:cc:cc:cc:cc  
          inet adr:90.0.0.2  Bcast:90.0.0.255  Masque:255.255.255.0
          adr inet6: fe80::21c:c0ff:feb9:829c/64 Scope:Lien
          adr inet6: 2001:a100:1:bbbb::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:113264620 errors:0 dropped:2523 overruns:0 frame:0
          TX packets:168526529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:59171827564 (55.1 GiB)  TX bytes:223993117711 (208.6 GiB)

Note the "dropped:2523" in the RX section. This is the most important. This number is continuously increasing.

ip -4 route show

default via 90.0.0.254 dev eth0 
90.0.0.0/24 dev eth0  proto kernel  scope link  src 90.0.0.2

ip -6 route show

2001:a100:1:bbbb::1/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:a100:1:bbff:ff:ff:ff:ff dev eth0  metric 1024

munin graph of plugin if_err_eth0_day

enter image description here

ifconfig

3 Answers

  1. http://www.novell.com/support/kb/doc.php?id=7007165

    Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:

    • Softnet backlog full
    • Bad / Unintended VLAN tags
    • Unknown / Unregistered protocols
    • IPv6 frames when the server is not configured for IPv6

    [...]

    If the rx_dropped counter stops incrementing while tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier.

    • 10

  2. I've been trying to track down this issue too to no avail. I've also noticed RX packet drops at the rate of about one per second on my Ubuntu 12 box. From my searching I've found people with similar issues on various other linux platforms, SUSE, Rpi, and others. Seems like something with the linux kernel. Some more interesting clues that I've noticed make the issue disappear temporarily, but not exactly explanations.

    1. If I change my config from static to DHCP in my /etc/network/interfaces the RX packet drops cease.Maybe the unrecognized packets t have something to do with DHCP and when it's off the box doesn't know what to do with them?

    2. If I run a tcpdump the packet drops cease while the dump is running and come back when I stop it.

    Maybe these clues will help get to the bottom of this?

    Overall my network performance appears to be just fine, just curious to as why this is happening too.

    • 2

  3. I've hunted this down for quite a while and finally managed to put together the pieces that resolve it - for me.

    The answer is given here https://superuser.com/questions/1421591/disable-homeplug-feature-on-fritzbox .

    In my case it's a FRITZ!Box 7590 that generates packets with protocol 0x88E1 and 0x8912 at an average rate of one per second as seen with ifconfig which are "dropped at the network interface level" (wording by netdata) on my PC. Dropping them using the XDP filter given at the above mentioned page resolves this. I.e. the RX dropped counter of ifconfig stops increasing.

    I managed to narrow the problem down using wireshark with a filter expression "!(eth.addr == yo:ur:ma:ca:dd:re) && !(ip.addr == 192.168.5.255)". I.e. show only packets not directly addressed to my machine or the IP broadcast address of my network. That removed enough of the noise to leave the offending traffic (plus ARP and some other low volume traffic). So if you don't have a FRITZ!Box which creates this issue for you then maybe that approach helps to identify which packets are causing the problem.

    One minor thing that's not quite clear to me yet, is that every two seconds three packets matching these protocols are received as can be observed with wireshark. This would make for an average rate of 1.5 dropped packets per second. Apparently only two of these three are "offending" so the XDP filter also drops one that wouldn't be a problem. But I guess I can live with that.

    • 1