Linux 上有没有办法获取有关数据包丢失的各种原因的统计数据?
在几台服务器的所有网络接口(openSUSE 12.3)上,ifconfig
和netstat -i
报告接收时丢包。当我执行 时tcpdump
,丢包数停止增加,这意味着接口队列未满并丢弃数据。因此,一定有其他原因导致这种情况发生(例如,接收到多播数据包,而接口不是此多播组的一部分)。
我在哪里可以找到这样的信息?(/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
答案1
尝试/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 驱动程序,确切含义也是如此。以上内容来自 Intel e1000
。查看了少数驱动程序后,发现有些驱动程序收集的统计数据比其他驱动程序多得多(ethtool 可用的统计数据往往保存在单独的源文件中,例如drivers/net/ethernet/intel/e1000/e1000_ethtool.c
,如果您需要翻找的话)。
ethtool -i eth0
将显示驱动程序的详细信息,输出lspci -v
应该更详细,尽管也有点混乱。
更新
在tg3.c
函数中tg3_rx()
只有一个地方看起来可能带有tp->rx_dropped++
,但代码中到处都是s,因此除了显而易见的原因(即带有 或 的goto
任何内容)之外,还有其他几个原因。(请注意,丢弃计数器是驱动程序维护的少数计数器之一,其余计数器由设备本身维护。)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
如果传输系统办公室/月球勘测轨道飞行器已启用(解释)。
答案2
错误表明模式和速度协商不良或不正确,或者网线损坏
丢弃表示可能由于 iptables 或其他过滤规则,更可能是由于网络缓冲内存不足
溢出指示网络接口用尽缓冲区空间的次数。载体网络电缆损坏或连接不良,或交换机问题
collsns 表示冲突数,在交换 LAN 上应始终为零。非零表示协商适当双工模式时出现问题。小数字永不增长意味着它在接口启动时发生,但此后没有发生过