Dropped packets in all Linux and Unix

linux networking linux-networking vlan ethernet

25,974

Probably what's happening is that you're seeing IPv6 broadcast traffic on your subnet, as per what you posted from a tcpdump output here:

12:19:41.622297 IP6 (hlim 1, next-header UDP (17) payload length: 112) fe80::a4a0:460b:c99a:c992.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=455863 (elapsed-time 700) (client-ID hwaddr/time type 1 time 495735714 e03f49b54e07) (IA_NA IAID:65027913 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))

And as per what you wrote in your question here:

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 -- (Measured from /proc/net/softnet_stat)

Bad / Unintended VLAN tags

Unknown / Unregistered protocols

IPv6 frames when the server is not configured for IPv6

If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.

From your output and your question, it would seem that you indeed have IPv6 disabled on the server.

This leads me to the conclusion that the dropped packets you're seeing is likely due to IPv6 broadcast traffic from other hosts on the network.

In order to test this, you can re-enable IPv6 and see if the dropped packets go away. If they do, this is harmless.

25,974

Valeriu

Updated on September 18, 2022

Comments

Valeriu over 1 year

I have a problem. I have a motherboard by Supermicro – X11SBA-LN4F. There are 4 ethernet ports. In the first port I connect to the internet. In the second port I connect to my local network.

When, I write ifconfig or netstat -i, I can see on my second interface (my local network) dropped packets. This count is incremented

em2       Link encap:Ethernet  HWaddr 0c:c4:7a:7b:91:3e
          inet addr:192.168.110.181  Bcast:192.168.110.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17441 errors:0 dropped:1380 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1226317 (1.2 MB)  TX bytes:0 (0.0 B)

After my search from google, I found this: https://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  -- (Measured from /proc/net/softnet_stat)
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6

If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.

First of all, I have written this command:

tcpdump -vv -i em2

While this command is running, the count of dropped packets on my second interface is stopped. But, when I abort tcpdump, the count of dropped packets is incremented again.

I disabled IPv6
I checked all VLANS. On that port I have only one Untag VLAN in local network
I checked the file /proc/net/softnet_stat. In that file I have info from only first column and that is good

00000013 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00002fbc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000f3 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000268f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
I analyzed by "tcpdump" all traffic. I have only – ARP Request, Broadcats and Rip. And it is not bad
I enabled promiscuous mode, but that didn't help
I checked cables and connectors
I install the latest driver
I increased ring caches size, but that didn't help

And I checked all Unix and Linux: Zeroshell, Pfense, FreeBsd, Ubuntu Server (with native kernel & compiled by me), CentOS (with native kernel & compiled by me). All showed the same symptoms.

ethtool -i em2

driver: igb
version: 5.3.4.4
firmware-version: 3.25, 0x800005d0
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

All statistic on that interface:

ethtool -S em2

NIC statistics:
     rx_packets: 29675
     tx_packets: 0
     rx_bytes: 2208735
     tx_bytes: 0
     rx_broadcast: 29636
     tx_broadcast: 0
     rx_multicast: 39
     tx_multicast: 0
     multicast: 39
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 2208735
     tx_dma_out_of_sync: 0
     lro_aggregated: 0
     lro_flushed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 0
     tx_queue_0_bytes: 0
     tx_queue_0_restart: 0
     rx_queue_0_packets: 29675
     rx_queue_0_bytes: 2090035
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0

Where is my problem? Please help me.

 ifconfig em2; ethtool -S em2


em2       Link encap:Ethernet  HWaddr 0c:c4:7a:7b:91:3e
          inet addr:192.168.110.181  Bcast:192.168.110.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15387 errors:0 dropped:1224 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1085031 (1.0 MB)  TX bytes:0 (0.0 B)

NIC statistics:
     rx_packets: 15387
     tx_packets: 0
     rx_bytes: 1146579
     tx_bytes: 0
     rx_broadcast: 15367
     tx_broadcast: 0
     rx_multicast: 20
     tx_multicast: 0
     multicast: 20
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 1146579
     tx_dma_out_of_sync: 0
     lro_aggregated: 0
     lro_flushed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 0
     tx_queue_0_bytes: 0
     tx_queue_0_restart: 0
     rx_queue_0_packets: 15387
     rx_queue_0_bytes: 1085031
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0

neutrinus almost 8 years

what about firewall: iptables -L ?
Valeriu almost 8 years

firewall is empty
Fox almost 8 years

My first guess judging by rx_long_byte_count would be to look at MTU. There may be jumboframes enabled on the switch and other nodes in the segment, but as this network card is set to use 1500 byte frames, it will drop anything longer than about 1522 bytes.
Valeriu almost 8 years

i disabled Jumbo Frame on SWITCH that connected to my ethernet port. but, that is no help
Valeriu almost 8 years

but in other segments in my network, JUMBO FRAME is enabled
Valeriu almost 8 years

i disabled all JUMBRO FRAME, but that is no help
Per von Zweigbergk almost 8 years

Can you post the output of ifconfig eth2;ethtool -S eth2? It would be interesting to compare the outputs of those from the same (or close to the same) point in time.
Valeriu almost 8 years

OK, no problem. 1 min plz.
Valeriu almost 8 years

i post it, look
Per von Zweigbergk almost 8 years

Odd. It would seem that from the output that you posted at the very bottom there's a discrepancy between the number of packets ifconfig sees and ethtool sees. ifconfig lists 10445 packets and 837 dropped (total 11282) whereas ethtool lists 10985 packets received. The discrepancy would seem to be too be too big if they were taken at the same time. Did you actually run the command as "one command" using a ; between them or just shortly after each other?
Valeriu almost 8 years

sorry, i fix it
Per von Zweigbergk almost 8 years

Is there any IPv6 in the broadcast traffic that you see using tcpdump?
Valeriu almost 8 years

i added you on skype. please confirm
Valeriu almost 8 years

12:19:41.622297 IP6 (hlim 1, next-header UDP (17) payload length: 112) fe80::a4a0:460b:c99a:c992.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=455863 (elapsed-time 700) (client-ID hwaddr/time type 1 time 495735714 e03f49b54e07) (IA_NA IAID:65027913 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))

Valeriu almost 8 years

i enabled IPV6, drop packets count are incremented
Per von Zweigbergk almost 8 years

This may also happen with other kinds of packets that Linux does not recognise, like LLDP, STP or loop-detect packets, just to give a few examples. Try using tcpdump to capture a file, and filter out everything that's not IP, and see what you get.
Valeriu almost 8 years

IP, ARP, IPX, IP6, RIPv2
Valeriu almost 8 years

if you have time. i can show for you my desktop or access control to it server, but with my control =)
Per von Zweigbergk almost 8 years

I don't see why I need to remote in your PC, you have your answer already. The IPX traffic may well for example be causing dropped packets.