Windows Server 2008 R2ネットワークアダプターが機能しなくなり、ハードリブートが必要になる
TL; DRバージョン：これは、Windows Server 2008 R2のBroadcomネットワーキングの深いバグであることがわかりました。 Intelハードウェアと交換することで修正されました。 Broadcomハードウェアを使用しなくなりました。これまでです。
Linux-HAプロジェクトの HAProxy とともに heartbeat を使用しています。フェイルオーバーを提供するために2つのLinuxインスタンスを使用しています。各サーバーには、独自のパブリックIPと、IPが69.59.196.211の仮想インターフェイス（eth1：1）を使用して2つのサーバー間で共有される単一のIPがあります。
仮想インターフェース（eth1：1）IP 69.59.196.211は、背後にあるWindowsサーバーのゲートウェイとして構成されており、トラフィックのルーティングにip_forwardingを使用しています。
Linuxゲートウェイの背後にあるWindowsサーバーの1つでネットワーク障害が発生することがあります。 HAProxyはサーバーがオフラインであることを検出します。これは、失敗したサーバーにリモート処理し、ゲートウェイにpingを送信することで確認できます。
32バイトのデータで69.59.196.211にpingします： 69.59.196.220からの応答：宛先ホストに到達できません。
ランニング arp -aこの失敗したサーバーでは、ゲートウェイアドレスのエントリがないことを示しています（69.59.196.211）：
インターフェース：69.59.196.220 --- 0xa インターネットアドレス物理アドレスタイプ 69.59.196.161 00-26-88-63-c7-80 dynamic 69.59 .196.210 00-15-5d-0a-3e-0e dynamic 69.59.196.212 00-21-5e-4d-45-c9 dynamic 69.59.196.213 00-15-5d-00- b2-0d dynamic 69.59.196.215 00-21-5e-4d-61-1a dynamic 69.59.196.217 00-21-5e-4d-2c-e8 dynamic 69.59 .196.219 00-21-5e-4d-38-e5 dynamic 69.59.196.221 00-15-5d-00-b2-0d dynamic 69.59.196.222 00-15-5d-0a- 3e-09 dynamic 69.59.196.223 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 static 224.0 .0.252 01-00-5e-00-00-fc static 225.0.0.1 01-00-5e-00-00-01 static
Linuxゲートウェイインスタンスでarp -aは以下を示します。
peak-colo-196-220.peak.org（69.59.196.220）at <incomplete> at eth1 stackoverflow.com（69.59.196.212）at 00：21：5e：4d：45 ：c9 [ether] on eth1 peak-colo-196-215.peak.org（69.59.196.215）at 00：21：5e：4d：61：1a [ether] on eth1 peak-colo-196-219.peak.org（69.59.196.219）at 00：21：5e：4d：38：e5 [ether] on eth1 peak-colo-196-222.peak.org（ 69.59.196.222）00：15：5d：0a：3e：09 [ether] eth1 peak-colo-196-209.peak.org（69.59.196.209）00：26：88：63 ：c7：80 [ether] on eth1 peak-colo-196-217.peak.org（69.59.196.217）at 00：21：5e：4d：2c：e8 [ether] on eth1
なぜarpはこの失敗したサーバーのエントリを<incomplete>として時々設定しますか？arpエントリを静的に定義する必要がありますか？ 99％の確率で動作するため、常にarpをそのままにしていましたが、この1つのインスタンスでは失敗しているようです。この問題の解決に役立つ追加のトラブルシューティング手順はありますか？
THINGS WE HAVE TRIED
Linuxゲートウェイの1つでテストするために静的arpエントリを追加しましたが、それでもまだ役に立ちませんでした。
root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1
root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms
Windows Webサーバーを再起動すると、ネットワークに他の変更を加えることなく一時的にこの問題が解決しますが、私たちの経験では、この問題が再発することがわかっています。
ネットワークカードとスイッチの交換
障害が発生したWindowsサーバーのスイッチのポートのリンクライトが、障害が発生したインターフェイスの1Gbではなく100Mbで実行されていることに気付きました。ケーブルを他のいくつかの開いているポートに移動しましたが、リンクは、試したポートごとに100Mbを示しました。私も同じ結果でケーブルを交換しました。 Windowsでネットワークカードのプロパティを変更しようとすると、サーバーがロックされ、[適用]をクリックした後にハードリセットが必要になりました。このWindowsサーバーには2つの物理ネットワークインターフェイスがあるため、2つのインターフェイスのケーブルとネットワーク設定を交換して、問題がインターフェイスに続くかどうかを確認しました。パブリックインターフェイスが再びダウンした場合は、ネットワークカードの問題ではないことがわかります。
（手元にある別のスイッチも試しましたが、変更はありません）
ネットワークハードウェアドライバーのバージョンの変更
最新のBroadcomドライバー、およびWindows Server 2008 R2に同梱されている組み込みドライバーでも同じ問題が発生しました。
ネットワークケーブルの交換
最後の努力として、発生した別の変更は、サーバー/スイッチ間のすべてのパッチコードの交換でした。プライベートインターフェイス用に1フィートから3フィートの長さのグリーンとパブリックインターフェイス用にもう1セットの赤いケーブルの2セットを購入しました。すべてのパブリックインターフェイスパッチケーブルを別のブランドに交換し、サーバーを問題なく1週間実行しましたが、問題は再発しました。
チェックサムオフロードを無効にし、TProxyを削除します
また、ドライバーのTCP/IPチェックサムオフロードを無効にしてみましたが、変更はありませんでした。 TProxyを引き出して、より伝統的なx-forwarded-for派手なIPアドレスの書き換えのないネットワーク構成。それが役立つかどうかを確認します。
スイッチ仮想化プロバイダー
偶然に、これは何らかの方法でHyper-Vに関連していたため（私たちはその上でHost Linux VMを実行しています）、VMWareサーバーに切り替えました。変化なし。
スイッチホストモデル
トラブルシューティングロープの終わりに達し、現在、マイクロソフトのサポートに正式に関与しています。ホストモデルの変更を推奨しました。
- http://en.wikipedia.org/wiki/Host_model
- http://technet.Microsoft.com/en-us/magazine/2007.09.cableguy.aspx
私たちはそれを行い、おそらく2008 R2 SP1に組み込まれたと思われる未公開のカーネルホットフィックスもいくつか入手しました。修正なし。
ネットワークカードハードウェアの交換
最終的に、BroadcomネットワークハードウェアをIntelネットワークハードウェアに交換すると、この問題は修正されました。そのため、Broadcom Windows Server 2008 R2ドライバーに問題があると思いがちです。
http://linux-ip.net/html/ether-arp.html から：
要求された宛先IPのARPキャッシュエントリが存在しない場合、カーネルは応答を受信するまでmcast_solicit ARP要求を生成します。この検出期間中、ARPキャッシュエントリは不完全な状態でリストされます。指定された数のARP要求の後に検索が成功しない場合、ARPキャッシュエントリは失敗した状態でリストされます。検索が成功した場合、カーネルはARPキャッシュに応答を入力し、確認タイマーと更新タイマーをリセットします。
ゲートウェイボックスが、ゲートウェイボックスからのARP要求に応答しない（または応答が遅すぎる）ようです。 <incomplete>は最終的に<failed>に切り替わりますか？サーバーとゲートウェイの間にどのようなネットワークハードウェアがありますか？ブロードキャストARP要求が2つのホスト間のどこかでフィルタリングまたはブロックされている可能性はありますか？
これは、アドレスに対してpingを実行したことを意味します。IPにはPTRレコード（したがって名前）がありますが、問題のマシンから応答がありません。これが表示される場合、最も一般的には、サブネットマスクが正しく設定されていないか、ループバックインターフェースにバインドされたIPが誤ってethインターフェースにバインドされていたことが原因です。
196.220とは何ですか？ 196.211との関係は何ですか？ .220がHAプロキシホストの1つであると想定しています。 ifconfig -a＆arp -aを実行すると、何が表示されますか？
Max Clarkが言うように、<incomplete>は69.59.196.211が69.59.196.220のARPリクエストを発行し、まだ応答を受け取っていないことを意味します。 （Windowsランドでは、これは "00-00-00-00-00-00"へのARPマッピングとして表示されます... BTWには、そのようなARPマッピングが表示されないのは奇妙に思えます69.59.196.220の場合は69.59.196.220。
私の経験では、ARPは通常、常にその仕事を行っているため、静的ARPエントリを使用するのは嫌いです。
私の場合、「障害のある」Windowsマシン（69.59.196.220）の適切なイーサネットインターフェイスをスニッフィングして、69.59.196.211のARPを監視し、69.59からのARP要求にどのように/応答しているかを確認します。 196.211。また、ゲートウェイマシンでARPのみをスニッフィングすることも検討します（tcpdump -i interface-name arp）Linuxマシンの側からARPトラフィックがどのように見えるかを確認します。
ブログ から、バックエンドネットワークとフロントエンドネットワークがあることがわかります。これらの停止中に、「障害のある」Windowsサーバー（69.59.196.220）は、フロントエンドネットワーク内の他のマシンとの通信に問題がありますか、それともゲートウェイとの通信に問題がありますか？あなたが行為でそれを捕らえているとき、あなたがフロントエンドまたはバックエンドネットワークを通してあなたが失敗したマシンに来ているかどうか私は興味があります。
問題が発生したときに「解決」するために何をしていますか？
編集：
アップデートから、問題を解決するために「失敗した」Windowsマシンを再起動していることがわかりました。次回それを行う前に、Windowsマシンがフロントエンドインターフェイスで「通信」できることを確認できますか？また、Windowsマシンからルーティングテーブルのコピーを取得します（route print）失敗時もそうです。 （NIC /ドライバーが基本的にWindowsマシンで失敗するかどうかを確認しようとしています。）
このドキュメント は、さまざまな状態を示しています（表2.1）。不完全な場合、最初のARP要求は送信されたが（おそらく古くなり、遅延し、プローブされた後）、まだ応答を受け取っていません。
Haproxyノードの静的ARPが役に立たない理由は、Webサーバーがまだゲートウェイに戻る方法を理解できないためです。
Webサーバー上の静的ARPは、Haproxyノードの1つに障害が発生したときにWebサーバーがゲートウェイを切り替える機能を破壊します-仮想インターフェイスがHaproxyノードのeth1と同じMACアドレスを共有していると思いますので、ハードにする必要があります各Webサーバーへの2つのゲートウェイの1つへのコード。
障害が発生しているWebサーバーに何らかのセキュリティソフトウェアがインストールされていますか？ Symantec Endpoint Securityが搭載されたWindows 2008サーバーで長い夜を過ごしました-フィルタリングコードをネットワークスタックにインストールして、ゲートウェイのARPパケットをまったく表示しないようにしました。その修正（Microsoftから提供されたもの）は、DLLをロードしたレジストリエントリを削除することでした。
この問題が発生した別の時間には、デバイスマネージャーからネットワークアダプター全体を削除して再インストールすることが役立つように思われました。
Arpエントリを静的に設定したので、サーバーknowゲートウェイを見つける場所。ただし、ゲートウェイがどこにあるかスイッチが認識していない場合、パケットは転送されません。
HAproxyとWebサーバーの間の切り替えが悪い（または混乱している）ようです。再起動します。
それか、HAproxyサーバーがどちらが制御しているかについて意見が分かれ、どちらも.211のarpルックアップに応答します。
同じように、スイッチが過負荷の場合、HAプロキシは十分な速度で相互に通信できず、フェイルオーバーしている可能性があります。
次にこの問題が発生したときは、問題の2つのホストでいくつかのパケットキャプチャを実行して、それぞれが監視しているARPトラフィックを特定することをお勧めします。
HAproxyマシンには、おそらく tcpdump のフレーバーがインストールされています。 Windowsマシンの場合、 WinPCAP アプリケーション（ Wireshark など）または Microsoft Network Monitor が必要です。
実際、それについて考えると、問題は特にARPにあるように見えるため、問題のHAproxyマシンとWindowsマシン上のすべてのARPトラフィックを、（議論のために）10MBのローリングキャプチャファイルを使用して継続的に記録する可能性があります。これは、障害を検出するまでに、キャプチャファイルに障害が発生する前のARPトラフィックが含まれるように十分な大きさにする必要があります。 （キャプチャーを1時間ほど実行して、生成されるデータ量を確認することをお勧めします）。
Linux tcpdumpのキャプチャ構文の例（注：これをテストするのに便利なLinuxボックスはありません。本番環境で使用する前に-Cおよび-Wの動作をテストしてください！）：
tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp
うまくいけば、何が失敗しているのかをある程度示すことができます。 ARPエントリが期限切れになると（そして この記事 によれば、Windowsの新しいバージョンは「非アクティブ」なエントリを非常に積極的にエージングアウトするように見えます）、次のことが起こると予想します。
- ソースホストは、ARP要求をターゲットホストに送信します。 ARP要求は一般にブロードキャストされますが、ホストが既存のエントリを更新している場合、ARPはユニキャストで送信されます。
- ターゲットホストはARP応答で応答します。 99％の確率でユニキャストになりますが、 [〜＃〜] rfc [〜＃〜] はブロードキャスト応答を許可します。 （詳細については、 IPv4アドレス衝突検出 に関するRFCも参照してください）。
簡単に言うと、このプロセスに干渉する可能性のある他のものがたくさんあります。
- 元のリクエストがターゲットに到達していない可能性があります。
- リクエストがターゲットに到達している可能性がありますが、レスポンスがソースに到達していない可能性があります。
- ある種の高可用性メカニズムがARPの「正常な」動作を妨げている可能性があります：
- HAProxyノード間のフェイルオーバーはどのように機能しますか？共有MACアドレスを使用しますか、それともGratuitous ARPを使用してノード間でIPアドレスをフェイルオーバーしますか？
- 上記のARPテーブルのMACアドレスの多くは、明らかにMicrosoftに登録されている00-15-5Dで始まります。問題のWindowsマシンでクラスタリングやその他のHAを使用していますか？これらの00-15-5D MACアドレスは、Windowsサーバーで「ipconfig/all」を実行したときにハードウェアNICに関連付けられているMACアドレスと同じですか？
これが再度発生するかどうか、また発生する場合の確認事項：
- ARPトラフィックのパケットキャプチャを見てください。会話の一部が明らかに発生していませんか？
- スイッチのブリッジング/ CAMテーブルを確認します。問題のすべてのMACアドレスは、それらが期待するポートにマッピングされますか？
- サブネット上の他のホストには、WindowsホストとHAProxyホストの両方のIPアドレスに対する有効なARPエントリがありますか？
- 複数の異なるソースマシン上の同じターゲットIPのARPエントリは、同じMACアドレスに解決されますか？つまり、サブネット上の他のいくつかのホストにログオンし、両方で196.211が同じMACアドレスに解決されることを確認します。
Asus Mainboard lanにも同じ問題がありました。 realtek ウェブサイトから最新のドライバーをインストールすることで修正されました
NIC上のすべてのトラフィックが停止するが接続されたままであり、NIC LEDが通信を示す。これは継続的な問題であり、週に2〜3回発生し続けましたが、稼働時間は約12〜13時間（サーバーは毎晩再起動される）になってからでした。
（好奇心から）NetbalancerServiceサービスを終了しようとした後、Seriousbit Netbalancerが原因であることがわかりました。その後、トラフィックはインターフェイスを通過し始めました。それ以来、Netbalancerをアンインストールしました。