Phantom NIC 问题导致 eth0/1 退出

Question

我们正在经历一个非常奇怪和令人沮丧的问题。我们公司在马萨诸塞州和加利福尼亚州都有服务器。我们看到的问题仅出现在 CA 硬件上。在加州，我们有数百台戴尔 R300 和戴尔 R310 服务器，它们都连接到四台 HP Procurve 4208vl 交换机。每个型号有两台交换机，一台用于前端网络，一台用于后端网络。这些系统排列在集群中，并且都用于我们运行的各种测试，以测试我们正在开发的软件操作系统。其中许多测试需要连续和/或重复重启。许多（如果不是大多数）测试会再次使用操作系统重新配置节点。问题是，如果有足够的时间，似乎是随机发生的，这些系统中的一个（或多个）将具有关闭的 eth0 或 eth1 接口。

问题是节点会间歇性地启动，eth0 或 eth1 上都没有连接，有时两者都没有。解决方法是通过后端（如果 eth0 已关闭）或前端（如果 eth1 已关闭）通过 SSH 进入并在已关闭的接口上运行 ifdown/ifup。

解决方法列表： - 服务网络重启 - ifdown eth1（或 eth0），然后 ifup eth1（或 eth0） - 重新安装网络电缆 - 重新启动服务器

这对开发团队来说是一个巨大的痛苦，因为它会阻止整个集群运行测试，直到手动干预。

最糟糕的部分发生在节点为操作系统安装启动 busybox 并且 eth0 退出时：在这种情况下，节点完全无法访问，因为我们在 busybox 中没有 eth1，并且操作系统安装无法继续，因为它不能与 PXE 服务器交谈以下拉操作系统的最新映像（因为 eth0 已关闭）。陷入这种状态的节点会像这样卡住，直到下次我在 CA 中接听某人的电话并让他手动重新启动节点。

已采取以下措施来尝试解决这个看似随机且无法重现的问题：

• Procurve Switch 和 R310 固件均已更新至最新版本。
• 交换机和服务器都设置为自动协商 (1000/FULL DUPLEX)。
• 我们在 4 台不同的 HP 交换机和大约 200-400 台戴尔服务器上看到了这种情况（它们都是在不同时间购买的，所以不仅仅是很多）。
• 我们在 CA 的其他硬件上没有这个问题，包括插入他们自己的 HP Procurve 交换机的戴尔 860 和 750。
• 当节点插入不同的交换机时，这个问题似乎不会发生（尽管我们缺乏在不同的交换机上进行全面测试的硬件）。

在固件升级之前，HP Procurve 交换机日志显示：

• 在端口 x 上检测到过多广播
• 端口 x 上的高冲突或丢弃率
• 端口 x 上过多的 CRC/对齐错误

固件升级后，我们看到的这些错误较少，但它们仍然存在。

为了排除故障，我一直在记录常用信息：

ifconfig ; for n in 0 1; do ethtool eth$n;ethtool -i eth$n;ethtool -k eth$n;ethtool 
-S eth$n; done; dmesg | egrep 'eth|bnx|e1000'; cat /var/log/messages > /tmp/eth_issues

以下是一些输出示例：

# ethtool -i eth0
driver: bnx2
version: 2.1.6
firmware-version: 6.4.5 bc 5.2.3 NCSI 2.0.11
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on

 # ethtool -S eth0
 NIC statistics:
 rx_bytes: 0
 rx_error_bytes: 0
 tx_bytes: 5676016
 tx_error_bytes: 0
 rx_ucast_packets: 0
 rx_mcast_packets: 0
 rx_bcast_packets: 0
 tx_ucast_packets: 0
 tx_mcast_packets: 7
 tx_bcast_packets: 10495
 tx_mac_errors: 0
 tx_carrier_errors: 0
 rx_crc_errors: 0
 rx_align_errors: 0
 tx_single_collisions: 0
 tx_multi_collisions: 0
 tx_deferred: 0
 tx_excess_collisions: 0
 tx_late_collisions: 0
 tx_total_collisions: 0
 rx_fragments: 0
 rx_jabbers: 0
 rx_undersize_packets: 0
 rx_oversize_packets: 0
 rx_64_byte_packets: 0
 rx_65_to_127_byte_packets: 0
 rx_128_to_255_byte_packets: 0
 rx_256_to_511_byte_packets: 0
 rx_512_to_1023_byte_packets: 0
 rx_1024_to_1522_byte_packets: 0
 rx_1523_to_9022_byte_packets: 0
 tx_64_byte_packets: 1054
 tx_65_to_127_byte_packets: 7
 tx_128_to_255_byte_packets: 0
 tx_256_to_511_byte_packets: 0
 tx_512_to_1023_byte_packets: 9441
 tx_1024_to_1522_byte_packets: 0
 tx_1523_to_9022_byte_packets: 0
 rx_xon_frames: 0
 rx_xoff_frames: 0
 tx_xon_frames: 0
 tx_xoff_frames: 0
 rx_mac_ctrl_frames: 0
 rx_filtered_packets: 0
 rx_ftq_discards: 0
 rx_discards: 0
 rx_fw_discards: 0

我们已经在与戴尔和惠普的电话上花费了无数个小时，但我们似乎无法弄清楚是什么导致了这个问题。起初我们认为固件升级会修复它，但在无处可去之后，两家公司都声称他们无法支持任何一方的硬件，并拒绝提供任何进一步的帮助。

有人可以帮我追踪这个问题的根本原因吗？请记住，我永远不知道什么时候或哪个系统会成为罪魁祸首，并且操作系统会被重新配置很多，因此安装软件来帮助记录这种情况是没有用的，因为它会在产品的下一次配置期间丢失。您可以提供的任何帮助或见解将不胜感激。也欢迎任何预感或想法。如果您需要更多详细信息或发布的输出，请告诉我。谢谢。

Answer 1

老实说，我怀疑目前这是硬件问题......而且更多的是您尝试启动的操作系统中的底层驱动程序的问题。根据我自己的经验，bnx2 驱动程序因非常糟糕而臭名昭著......因为它是由 Broadcom 编写的，试图让开源用户满意，但仅此而已。您是否尝试过直接从 Broadcom 下载/构建驱动程序？更有趣的是看看疯狂数量的广播数据包中有什么......（将其理解为尝试捕获 NIC 和交换机之间的数据包）并将其扔给 Boadcom 以获得反馈。旧交换机可能没有抱怨，因为它们没有费心处理大量的坏数据包......（新交换机上报告了大量错误）