我们遇到了一个非常奇怪和令人沮丧的问题。我们公司在马萨诸塞州和加利福尼亚州都有服务器。我们看到的问题只出现在 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，...）。