我们正在经历一个非常奇怪和令人沮丧的问题。 我们公司在马萨诸塞州和加利福尼亚州都有服务器。 我们看到的问题只在CA硬件上。 在加州，我们有数百台戴尔R300和戴尔R310服务器，全部连接到四台惠普Procurve 4208vl交换机。 每个型号有两个交换机，一个用于前端networking，另一个用于后端networking。 这些系统已经集成在一起，所有这些系统都被用于testing我们正在开发的软件操作系统的各种testing。 许多这些testing需要成功和/或重复重新启动。 许多，如果不是大多数的testing，再次用Os来重新提供节点。 问题是，如果发生的时间足够长，看起来随机，这些系统中的一个（或多个）将会有一个down掉的eth0或eth1接口。
问题是节点会间歇性地启动，eth0或eth1上都没有连接，有时两者都是。 解决方法是通过后端（如果eth0处于closures状态）或前端（如果eth1处于closures状态）进行SSH并在closures的接口上运行ifdown / ifup。
变通清单： – 服务networking重新启动 – ifdown eth1（或eth0），然后ifup eth1（或eth0） – 重新安装networking电缆 – 重新启动服务器
这对开发团队来说是一个巨大的痛苦，因为它会阻止整个集群运行testing，直到手动干预。
最糟糕的部分是当一个节点启动busybox进行操作系统安装，并且eth0退出：在这种情况下节点完全无法访问，因为我们在busybox中没有eth1，并且OS安装无法继续，因为它不能与PXE服务器交谈以下拉操作系统的最新映像（因为eth0处于closures状态）。 陷入这种状态的节点将陷入这样的困境，直到下一次我在电话中findCA中的某个人，让他手动重新启动节点。
为了解决这个看似随意和无法解决的问题，已经做了以下工作：
在固件升级之前，HP ProCurve切换日志显示：
固件升级后，我们看到这些错误较less，但仍然存在。
为了排除故障，我一直在logging通常的信息：
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
我们花了无数个小时与戴尔和惠普的电话，我们似乎无法弄清楚是什么原因造成这个问题。 起初我们认为固件升级可以解决这个问题，但是在两家公司都宣称无法支持任何一方的硬件的情况下，拒绝提供帮助。
有人可以帮我跟踪这个问题的根源？ 请记住，我永远不知道什么时候或哪个系统是罪魁祸首，操作系统会被重新提供，因此安装软件来帮助logging这些信息是毫无用处的，因为在产品下次供应期间它将会丢失。 任何帮助或见解你可以提供将不胜感激。 任何预感或想法也是受欢迎的。 请让我知道你是否需要更多的细节或输出张贴。 谢谢。
答案是：获得更好的NIC并注意自己永远不要再购买Broadcom：
老实说，我怀疑这是一个硬件问题在这一点上…更多的问题与操作系统中的底层驱动程序，你试图启动。 在我自己的经验中，bnx2驱动程序是非常糟糕的臭名昭着的…因为它是由Broadcom写的，试图让开源用户感到高兴，但不仅仅如此。 你有没有尝试直接从broadcom下载/build立驱动程序？ 查看广播数据包的数量是多less有趣的…（可以读取NIC和Switch之间的数据包），然后向Boadcom反馈。 旧的交换机可能没有投诉，因为他们没有打扰处理大量坏的数据包（新交换机报告的错误数量很高）
我们有一些R300和R310 – 启动后从来没有问题。 顺便说一句 – 戴尔支持对你的情况说什么？
所以我的猜测是硬件networking端（Procurve交换机）出了问题。 但是，如果我是你，我会写一个简单的解决方法：
在后期运行的init脚本，如果在eth0或eth1上未检测到链接，则执行ifdown / ifup。
顺便说一句：eth0和eth1都在船上？ 那么两者都应该能够进行PXE启动（我现在不在工作，所以我不知道板载接口的数量 – 我通常使用更大的兄弟R510，R710，…）。