![幻影网卡问题导致 eth0/1 掉线](https://linux22.com/image/571742/%E5%B9%BB%E5%BD%B1%E7%BD%91%E5%8D%A1%E9%97%AE%E9%A2%98%E5%AF%BC%E8%87%B4%20eth0%2F1%20%E6%8E%89%E7%BA%BF.png)
我们遇到了一个非常奇怪和令人沮丧的问题。我们公司在马萨诸塞州和加利福尼亚州都有服务器。我们看到的问题只出现在 CA 硬件上。在 CA,我们有数百台 Dell R300 和 Dell R310 服务器,全部连接到四个 HP Procurve 4208vl 交换机。每个型号都有两个交换机,一个用于前端网络,一个用于后端网络。这些系统排列成集群,都用于我们运行的各种测试,以测试我们正在开发的软件操作系统。许多测试都需要连续和/或重复重新启动。许多(如果不是大多数)测试都需要重新为节点配置操作系统。问题是,如果有足够的时间,这些系统中的一个(或多个)系统似乎会随机出现 eth0 或 eth1 接口故障的情况。
问题是节点会间歇性地启动,但 eth0 或 eth1 上没有连接,有时两者都没有连接。解决方法是通过后端(如果 eth0 已关闭)或前端(如果 eth1 已关闭)通过 SSH 进入,并在已关闭的接口上运行 ifdown/ifup。
解决方法列表: - 服务网络重新启动 - ifdown eth1(或 eth0),然后 ifup eth1(或 eth0) - 重新安装网线 - 重新启动服务器
这对开发团队来说是一个巨大的痛苦,因为它会阻止整个集群运行测试,直到人工干预。
最糟糕的情况是,当节点启动 busybox 进行 OS 安装时,eth0 断开连接:在这种情况下,由于 busybox 中没有 eth1,因此节点完全无法访问,并且 OS 安装无法继续,因为它无法与 PXE 服务器通信以下载最新的 OS 映像(因为 eth0 已关闭)。陷入这种状态的节点将一直卡住,直到下次我打电话给加州的人并让他手动重新启动节点。
为了尝试解决这个看似随机且无法重现的问题,我们采取了以下措施:
- Procurve Switch 和 R310 固件均已更新至最新版本。
- 交换机和服务器都设置为自动协商(1000/全双工)。
- 我们在 4 个不同的 HP 交换机和大约 200-400 台戴尔服务器上看到了这种情况(它们都是在不同时间购买的,因此并不是一批坏的)。
- 在 CA 的其他硬件上我们没有遇到这个问题,包括插入自己的 HP Procurve 交换机的 Dell 860s 和 750s。
- 当节点插入不同的交换机时,似乎不会发生此问题(尽管我们缺乏在不同交换机上进行完整测试的硬件)。
固件升级之前,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
我们花了无数个小时与戴尔和惠普通电话,但似乎无法找出导致此问题的原因。起初我们以为固件升级可以解决这个问题,但毫无进展之后,两家公司都声称他们无法支持任何一方的硬件,并拒绝提供任何进一步的帮助。
有人能帮我追踪这个问题的根本原因吗?请记住,我永远不知道什么时候或哪个系统会是罪魁祸首,而且操作系统被重新配置了很多次,所以安装软件来帮助记录这个是没用的,因为它会在产品的下一次配置中丢失。如果您能提供任何帮助或见解,我们将不胜感激。也欢迎任何预感或想法。如果您需要更多详细信息或输出,请告诉我。谢谢。
答案1
答案是:购买更好的网卡,并记住永远不再购买 Broadcom:
答案2
老实说,我怀疑现在这不是硬件问题……而更像是您尝试启动的操作系统中的底层驱动程序问题。以我自己的经验来看,bnx2 驱动程序非常糟糕……因为它是由 Broadcom 编写的,旨在让开源用户满意,但仅此而已。您是否尝试过直接从 Broadcom 下载/构建驱动程序?看看大量广播数据包中有什么会更有趣……(将其理解为尝试在 NIC 和交换机之间捕获数据包)并将其发送给 Boadcom 以征求反馈。旧交换机可能没有抱怨,因为它们没有费心处理大量坏数据包……(新交换机上报告的错误数量很高)
答案3
我们有许多 R300 和 R310 - 启动后从未出现过问题。顺便问一下 - 戴尔支持对您的案例有何评价?
所以我猜想硬件的网络端(Procurve 交换机)出了问题。但是如果我是你,我会写一个简单的解决方法:
在后期运行的 init 脚本,如果在 eth0 或 eth1 上未检测到链接,则执行 ifdown/ifup。
顺便问一下:eth0 和 eth1 都在板上吗?那么两者都应该能够进行 PXE 启动(我现在不在工作,所以不确定板载接口的数量 - 我通常使用更大的兄弟 R510、R710,...)。