ファントムNIC eth0 / 1がドロップアウトする問題
私たちは非常に奇妙で苛立たしい問題を経験しています。当社は、ここマサチューセッツとカリフォルニアにサーバーを持っています。私たちが見ている問題は、CAハードウェアにのみあります。 CAには、数百台のDellR300サーバーとDellR310サーバーがあり、すべて4つのHP Procurve4208vlスイッチに接続されています。モデルごとに2つのスイッチがあります。1つはフロントエンドネットワーク用で、もう1つはバックエンドネットワーク用です。これらのシステムはクラスターに配置されており、開発中のソフトウェアOSをテストするために実行するさまざまなテストにすべて使用されます。これらのテストの多くは、再起動を繰り返したり、繰り返したりする必要があります。ほとんどのテストではないにしても、多くの場合、ノードにOを再度プロビジョニングします。問題は、十分な時間が与えられると、一見ランダムに見えるため、これらのシステムの1つ（または多く）でeth0またはeth1インターフェイスがダウンすることです。
問題は、ノードが間欠的に起動し、eth0またはeth1のいずれか、場合によっては両方に接続がないことです。回避策は、バックエンド（eth0がダウンしている場合）またはフロントエンド（eth1がダウンしている場合）を介してSSHで接続し、ダウンしたインターフェイスでifdown/ifupを実行することです。
回避策のリスト：-サービスネットワークの再起動-ifdown eth1（またはeth0）、次にifup eth1（またはeth0）-ネットワークケーブルを取り付け直します-サーバーを再起動します
これは、手動で介入するまでクラスター全体がテストを実行できなくなるため、開発チームにとって大きな苦痛です。
最悪の部分は、ノードがOSインストールのためにbusyboxを起動し、eth0がドロップアウトしたときに発生します。この場合、busyboxにeth1がないため、ノードに完全に到達できず、OSインストールを続行できないために続行できません。 PXEサーバーに話しかけて、OSの最新のイメージをプルダウンします（eth0がダウンしているため）。この状態に陥ったノードは、次にCAの誰かに電話をかけて、手動でノードを再起動させるまで、このようにスタックします。
この一見ランダムで再現不可能な問題を解決するために、次のことが行われました。
- Procurve SwitchとR310ファームウェアの両方が、可能な限り最新のリビジョンに更新されています。
- スイッチとサーバーの両方が自動ネゴシエーション（1000 /全二重）に設定されています。
- これは、4つの異なるHPスイッチと約200〜400台のDellサーバーで見られます（これらはすべて異なる時期に購入されたため、悪いロットではありません）。
- 独自のHPProcurveスイッチに接続されたDell860および750を含む、CAの他のハードウェアではこの問題は発生しません。
- この問題は、ノードが別のスイッチに接続されている場合には発生しないようです（ただし、別のスイッチで完全にテストするためのハードウェアが不足しています）。
ファームウェアをアップグレードする前は、HPProcurveスイッチのログに次の情報が表示されます。
- ポート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
デルとHPとの電話で数え切れないほどの時間を費やしてきましたが、この問題の原因を特定できないようです。最初はファームウェアのアップグレードで修正できると思っていましたが、どこにも行かなかった後、両社はどちらの当事者のハードウェアもサポートできないと主張し、それ以上の支援を拒否しました。
誰かがこの問題を根本原因まで追跡するのを手伝ってもらえますか？いつ、どのシステムが原因であるかわからず、OSが頻繁に再プロビジョニングされることを覚えておいてください。したがって、これをログに記録するのに役立つソフトウェアをインストールしても、製品の次のプロビジョニング中に失われるため、役に立ちません。あなたが提供できるどんな助けや洞察もいただければ幸いです。どんな勘や考えも大歓迎です。詳細や出力の投稿が必要な場合はお知らせください。ありがとう。
答えは次のとおりです。より良いNICを取得し、Broadcomを二度と購入しないように注意してください。
正直なところ、現時点ではハードウェアの問題ではないかと思います...さらに、起動しようとしているOSの基盤となるドライバーの問題です。私自身の経験では、bnx2ドライバーはかなりひどいことで有名です...オープンソースユーザーを幸せにするためにBroadcomによって書かれているので、それ以上ではありません。 Broadcomから直接ドライバーをダウンロード/構築してみましたか？ブロードキャストパケットの異常な量に何が含まれているかを確認する方が興味深いでしょう...（NIC＆Switch）の間でパケットをキャプチャして、フィードバックのためにBoadcomにスローしてみてください。古いスイッチは、不良パケットのフラッドに対処しなかったため、文句を言わなかった可能性があります...（新しいスイッチで大量のエラーが報告されました）
R300とR310がいくつかありますが、起動後に問題が発生することはありませんでした。ところで、デルのサポートはあなたのケースに何と言っていますか？
したがって、ハードウェア（Procurve Switch）のネットワーク側に問題があると思います。ただし、私があなたである場合は、簡単な回避策を作成します。
後期段階で実行され、eth0またはeth1でリンクが検出されない場合にifdown/ifupを実行するinitスクリプト。
ところで：eth0とeth1は両方とも搭載されていますか？そうすれば、両方がPXEブートを実行できるはずです（私は現在仕事をしていないので、オンボードインターフェイスの数がわかりません-私は通常、兄のR510、R710などを使用します）。