如何找出网络接口丢弃数据包的原因？

Linux上是否有一种方法可以获取有关丢弃数据包的各种原因的统计信息？

在多台服务器的所有网络接口（openSUSE 12.3）上，ifconfig并netstat -i在接收时报告丢弃的数据包。当我执行a时tcpdump，丢弃的数据包的数量停止增加，这意味着接口队列未满并丢弃了数据。因此，一定有其他原因导致这种情况发生（例如，接收到多播pkts，而接口不属于此多播组）。

在哪里可以找到此类信息？（/ proc？/ sys？一些日志？）

统计信息示例（/ sys / class / net / <dev> / statistics和ethtool输出的合并）：

alloc_rx_buff_failed: 0
collisions: 0
dropped_smbus: 0
multicast: 1644
rx_align_errors: 0
rx_broadcast: 23626
rx_bytes: 1897203
rx_compressed: 0
rx_crc_errors: 0
rx_csum_offload_errors: 0
rx_csum_offload_good: 0
rx_dropped: 4738
rx_errors: 0
rx_fifo_errors: 0
rx_flow_control_xoff: 0
rx_flow_control_xon: 0
rx_frame_errors: 0
rx_length_errors: 0
rx_long_byte_count: 1998731
rx_long_length_errors: 0
rx_missed_errors: 0
rx_multicast: 1644
rx_no_buffer_count: 0
rx_over_errors: 0
rx_packets: 25382
rx_short_length_errors: 0
rx_smbus: 0
tx_aborted_errors: 0
tx_abort_late_coll: 0
tx_broadcast: 7
tx_bytes: 11300
tx_carrier_errors: 0
tx_compressed: 0
tx_deferred_ok: 0
tx_dropped: 0
tx_errors: 0
tx_fifo_errors: 0
tx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_heartbeat_errors: 0
tx_multicast: 43
tx_multi_coll_ok: 0
tx_packets: 63
tx_restart_queue: 0
tx_single_coll_ok: 0
tx_smbus: 0
tx_tcp_seg_failed: 0
tx_tcp_seg_good: 0
tx_timeout_count: 0
tx_window_errors: 0

尝试/sys/class/net/eth0/statistics/ （例如eth0），它不是完美的方法，但是它可以通过发送/接收以及载波，窗口，fifo，crc，帧，长度（以及更多）错误类型来分解错误。

netstat丢弃与“忽略”不同，显示接口级别统计信息，被更高级别（第3层，IP堆栈）忽略的多播数据包不会显示为丢弃（尽管在某些情况下它可能显示为“已过滤”） NIC统计信息）。各种卸载功能可能会使统计数据有些复杂。

如果您有ethtool以下内容，则可以获得更多统计信息：

# ethtool -S eth0
 rx_packets: 60666755
 tx_packets: 2206194
 rx_bytes: 6630349870
 tx_bytes: 815877983
 rx_broadcast: 58230114
 tx_broadcast: 9307
 rx_multicast: 8406
 tx_multicast: 17
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 8406
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 [...]

某些统计信息取决于NIC驱动程序，确切含义也取决于此。以上是英特尔公司提供的e1000。在查看了少数驱动程序后，有些驱动程序收集的统计数据比其他驱动程序多（ethtool可用的统计数据倾向于保存在单独的源文件中，例如drivers/net/ethernet/intel/e1000/e1000_ethtool.c，如果您需要翻阅）。

ethtool -i eth0会显示驱动程序详细信息，的输出lspci -v应该更详细，尽管也有些混乱。

在tg3.c函数Update中，tg3_rx()只有一个位置看起来可能带有tp->rx_dropped++，但代码中带有gotos，所以除了显而易见的原因外，还有其他原因，例如，带有goto drop_it 或的任何原因goto drop_it_no_recycle。（请注意，下降计数器是由驾驶员维护的少数计数器之一，其余的由设备本身维护。）

我要处理的驱动程序源是3.123。我最好的猜测是这段代码：

           if (len > (tp->dev->mtu + ETH_HLEN) &&
                skb->protocol != htons(ETH_P_8021Q)) {
                    dev_kfree_skb(skb);
                    goto drop_it_no_recycle;
            }

检查MTU，可能的原因是巨型帧或稍微超大的以太网帧，以便进行封装。我无法解释为什么tcpdump可能会更改行为，更改接口MTU尚不清楚。还请注意，tcpdump如果启用了TSO / LRO，则可能“看到”比MTU大的数据包（说明）。