ifconfig shows

[tweeshen]

Hi, we are seeing a large number of RX packets dropped when we do a ifconfig command.
Would like to check if there is known new driver or firmware from Centos that we may have missed out patching.

[hunter86_bg]

If ethtool test do not report any issues ,then it's most probably a vlan traffic hitting your nics.

[tweeshen]

Thanks for the suggestion. Are there any tests that I could do to proof that vlan is probably the cause?

[gaguilera]

Have you tested it without bonding? In my case only happens when I configure a bridged interface.

[hunter86_bg]

The best test is to create a short trace via :

Code: Select all

tcpdump -i interface -w file_to_write.pcap

Then check if there is untagged traffic arriving. If it's not - then the "ethtool" has a test option.

Note: A colleague warned me that the test option of ethtool could disrupt the connectivity of the NIC!

[tweeshen]

I have tested it without bonding. I removed the bonding and used only 1 NIC. Still getting RX packet dropped

[hunter86_bg]

Have you done any ethtool tests ?
Short quotation of the ethtool's man page:

-t --test
Executes adapter selftest on the specified network device. Pos‐
sible test modes are:

offline
Perform full set of tests, possibly interrupting normal op‐
eration during the tests,

online Perform limited set of tests, not interrupting normal opera‐
tion,

external_lb
Perform full set of tests, as for offline, and additionally
an external-loopback test.

[tweeshen]

Yes, we have done ethtool but doesn't show much information. I came across this link http://www.linuxquestions.org/questions ... 175507861/

It shared that 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

A quick way to test this (WARNING: this test does not work for bonding interfaces) is to start a packet capture:

host:~# tcpdump

And then watching the rx_dropped counter. If it stops incrementing while the tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier. If frames continue to be dropped while running tcpdump, investigation should take place to determine root cause.

I tested this and the RX packet stopped dropping. However, when I put the NIC in promiscuous mode, it registered packet dropped, though the number is small; in tens per min. The two different results are puzzling.

[hunter86_bg]

Do you have access to the switch before the server? In this case you might try to capture from there and see what's being sent to the server.