Inbound_packets_dropped_ratio

Alerts
1

inbound_packets_dropped_ratio

OS: Linux

Packet drops indicate that your system received some packets but could not process them. A sizeable amount of packet drops can consume significant amount of resources in your system. Some reasons that packets drops occurred in your system could be:

  • Your system receives packets with bad VLAN tags.
  • The packets you are receiving are using a protocol that is unknown to your system.
  • You receive IPv6 packets, but your system is not configured for IPv6.

All these packets consume resources until being dropped (and for a short period after). For example, your NIC stores them in a ring-buffer until they are forwarded to the destined subsystem or userland application for further process.

Netdata agent calculates the ratio of inbound dropped packets for your wired network interface over the last 10 minutes.

Troubleshooting section:

The best way to resolve these kinds of problems is to be extremely knowledgeable about your network topologies. These are some actions you might consider check:

Identify VLANs in your interface

There are cases in which traffic is routed to your host due to the existence of multiple VLAN in your network.

  1. Identify VLAN tagged packet in your interface.

    root@netdata ~ # tcpdump -i <your_interface> -nn -e  vlan

  2. Monitor the output of the tcpdump, identify VLANs which may exist. If no output is displayed, your interface probably uses traditional ethernet frames.

  3. Depending on your network topology, you may consider removing unnecessary VLANs from the switch trunk port
    toward your host.

Update the ring buffer size on your interface

  1. To view the maximum RX ring buffer size:

    root@netdata ~ # ethtool -g enp1s0
Ring parameters for enp1s0:
Pre-set maximums:
RX:             4080
RX Mini:        0
RX Jumbo:       16320
TX:             255
Current hardware settings:
RX:             255
RX Mini:        0
RX Jumbo:       0
TX:             255

  2. If the values in the Pre-set maximums section are higher than in the current hardware settings section, increase RX ring buffer:

    root@netdata ~ # enp1s0 rx 4080

  3. Verify the change to make sure that you no longer receive the alarm when running the same workload. To make this permanently, you must consult your distribution guides.

Inspect the packets your network interface receives

Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software andcommunications protocol development.

See more about Wireshark here

2

I found this thread from the email that alert the alarm.
I do not know if in the meantime something more updated is available (not found if it exists)
The strange scenario I have is that many machines in the server rooms I manage, present the problem. But:

  • Linux OS does not report it (I checked with typical: netstat, ethtool,…)
  • Only certain category of machines present this. I have different Linux distro so this is not the case. But I use machines for 3 cases: OracleDB or VirtualMachine hosts or Routing/Firewall. And only category 2 and 3 have the issue. No machine with OracleDB have it. The difference is only that I have QEMU on VirtualHosts. After this I do not recognize other difference in settings
  • the entire network does not have VLAN

is there something more I can inspect?

3

ifconfig will display them as dropped i.e.:
RX errors 0 dropped 8145559 overruns 0 frame 0