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

前端之家收集整理的这篇文章主要介绍了linux – 如何找出网络接口丢弃数据包的原因?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
有没有办法在 Linux获取有关丢弃数据包的各种原因的统计信息?

在多个服务器上的所有网络接口(openSUSE 12.3)上,ifconfig和netstat -i在接收时报告丢弃的数据包.当我执行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 show interface level statistics,更高级别忽略的多播数据包(第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驱动程序,具体含义也是如此.以上内容来自Intel e1000.看过少数几个驱动程序后,有些人会收集更多的统计信息(ethtool可用的统计信息往往保存在单独的源文件中,例如drivers / net / ethernet / intel / e1000 / e1000_ethtool.c,如果你需要翻找) .

ethtool -i eth0将显示驱动程序的详细信息,lspci -v的输出应该更详细,尽管也有点杂乱.

更新
在tg3.c函数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,可能的原因是巨型帧,或slightly oversized ethernet frames以允许封装.我无法解释为什么tcpdump可能会改变行为,不知道改变接口MTU.另请注意,如果启用TSO/LRO(explanation),您可以使用tcpdump“查看”大于MTU的数据包.

猜你在找的Linux相关文章