Windows Server 2008 R2ネットワークアダプターが動作を停止し、ハードリブートが必要

TL; DRバージョン：これは、Windows Server 2008 R2のBroadcomネットワークの深いバグであることが判明しました。Intelハードウェアと交換すると修正されました。Broadcomハードウェアは使用しなくなりました。今まで。

Linux-HAプロジェクトのハートビートとともにHAProxyを使用しています。フェイルオーバーを提供するために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ダイナミック
69.59.196.210 00-15-5d-0a-3e-0eダイナミック
69.59.196.212 00-21-5e-4d-45-c9ダイナミック
69.59.196.213 00-15-5d-00-b2-0d動的
69.59.196.215 00-21-5e-4d-61-1aダイナミック
69.59.196.217 00-21-5e-4d-2c-e8ダイナミック
69.59.196.219 00-21-5e-4d-38-e5ダイナミック
69.59.196.221 00-15-5d-00-b2-0d動的
69.59.196.222 00-15-5d-0a-3e-09ダイナミック
69.59.196.223 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16静的
224.0.0.252 01-00-5e-00-00-fc静的
225.0.0.1 01-00-5e-00-00-01静的

Linuxゲートウェイでは、インスタンスarp -aは以下を示します。

peak-colo-196-220.peak.org（69.59.196.220）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）at 00：15：5d：0a：3e：09 [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

なぜarpは、この失敗したサーバーのエントリを<incomplete>として設定するのですか？ arpエントリを静的に定義する必要がありますか？それは99％の時間で動作するため、私は常にarpをそのままにしてきましたが、この1つの例では失敗しているようです。この問題の解決に役立つトラブルシューティング手順はありますか？

試したもの

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に同梱されている組み込みドライバーでも同じ問題が発生しました。

ネットワークケーブルの交換

最後の溝の努力として、発生した別の変更は、サーバー/スイッチ間のすべてのパッチコードの交換であったことを思い出しました。私たちは2セットを購入しました。1つはプライベートインターフェイス用の長さ1フィート-3フィートの緑、もう1つはパブリックインターフェイス用の赤いケーブルのセットです。すべてのパブリックインターフェイスパッチケーブルを別のブランドのものに交換し、サーバーを1週間問題なく実行しました。

チェックサムオフロードを無効にし、TProxyを削除します

また、ドライバーでTCP / IPチェックサムオフロードを無効にしてみましたが、変更はありません。現在、TProxyを撤回し、x-forwarded-forIPアドレスを空想することなく、従来のネットワーク配置に移行しています。それが役立つかどうかを確認します。

スイッチ仮想化プロバイダー

偶然、これが何らかの形でHyper-Vに関連していた（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://blog.serverfault.com/post/broadcom-die-mutha/

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マッピングとして表示されます...ところで、このようなARPマッピングが表示されないのは奇妙なようです。 69.59.196.220の場合は69.59.196.220）

私の経験では、ARPは常にその仕事をしているので、静的ARPエントリを使用するのは好きではありません。

私の場合は、「障害が発生している」Windowsマシン（69.59.196.220）の適切なイーサネットインターフェイスをスニッフィングして、69.59.196.211のARP'ingを観察し、69.59からのARP要求に応答するかどうかを観察します。 196.211。また、ARPのみのゲートウェイマシンでスニッフィングを検討して（tcpdump -i interface-name arp）、Linuxマシンの側面からのARPトラフィックがどのように見えるかを確認します。

ブログから、バックエンドネットワークとフロントエンドネットワークがあることを知っています。これらの停止中に、「障害のある」Windowsサーバー（69.59.196.220）は、フロントエンドネットワーク内の他のマシンとの通信に問題がありますか、それともゲートウェイとの通信に問題がありますか？障害が発生したマシンをフロントエンドネットワークまたはバックエンドネットワーク経由でアクセスしていて、実際にそれをキャッチしている場合、私は興味があります。

問題が発生したときに「解決」するために何をしていますか？

編集：

更新から、問題を解決するために「障害のある」Windowsマシンを再起動していることがわかります。次回それを行う前に、Windowsマシンがフロントエンドインターフェイスで「通信」できることを確認できますか？また、route print障害時にもWindowsマシン（）からルーティングテーブルのコピーを取得します。（基本的に、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エントリを静的に設定しているため、サーバーはゲートウェイの場所を認識しています。ただし、スイッチがゲートウェイの場所を認識していない場合、パケットは転送されません。

HAproxyとWebサーバーの切り替えが悪い（または混乱している）ようです。再起動します。

それか、HAproxyサーバーのどちらが制御中であるかについて意見が一致せず、両方とも.211のarpルックアップに応答します。

同じ行に沿って、スイッチが過負荷になると、HAproxiesは相互に十分な速度で通信できず、フェールオーバーする可能性があります。

次回この問題が発生したときに、問題の2つのホストでパケットキャプチャを実行して、それぞれが監視しているARPトラフィックを判断することをお勧めします。

HAproxyマシンには、ほとんどの場合、tcpdumpがインストールされています。Windowsマシンの場合、WiresharkなどのWinPCAPアプリケーション、または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の新しいバージョンは「非アクティブな」エントリを非常に積極的にエージングアウトするように見えます）、次のことが起こると予想されます。

1. ソースホストは、ターゲットホストにARP要求を送信します。ARP要求は通常ブロードキャストされますが、ホストが既存のエントリを更新している場合、ARPはユニキャストで送信される場合があります。
2. ターゲットホストはARP応答で応答します。99％の時間、これはユニキャストになりますが、RFCはブロードキャスト応答を許可します。（詳細については、IPv4アドレス衝突検出に関するRFCも参照してください）。

簡単に聞こえますが、このプロセスに干渉する可能性のある他のことがたくさんあります。

• 元のリクエストがターゲットに到着していない可能性があります。
• 要求はターゲットに到着している可能性がありますが、応答がソースに到達していない可能性があります。
• 何らかの高可用性メカニズムがARPの「通常の」動作を妨害している可能性があります。
  • HAProxyノード間のフェールオーバーはどのように機能しますか？共有MACアドレスを使用しますか、それともgratuitous ARPを使用してノード間でIPアドレスをフェールオーバーしますか？
  • 上記のARPテーブルのMACアドレスの多くは、00-15-5Dで始まります。これは明らかにMicrosoftに登録されています。問題のWindowsマシンでクラスタリングまたはその他のHAを使用していますか？これらの00-15-5D MACアドレスは、Windowsサーバーで「ipconfig / all」を実行したときにハードウェアNICに関連付けられているのと同じものですか？

これが再び起こるかどうか/いつ起こるかをチェックするもの：

• ARPトラフィックのパケットキャプチャを見てください。会話の一部が明らかに発生していませんか？
• スイッチのブリッジング/ CAMテーブルを確認してください。問題のすべてのMACアドレスは、期待するポートにマッピングされますか？
• サブネット上の他のホストには、WindowsホストとHAProxyホストの両方のIPアドレスに対する有効なARPエントリがありますか？
• 複数の異なるソースマシン上の同じターゲットIPのARPエントリは、同じMACアドレスに解決されますか？すなわち、サブネット上の他のいくつかのホストにログオンし、196.21が両方の同じMACアドレスに解決されることを確認します。

2008 R2ターミナルサーバーの1つで同様の問題が発生し、NIC上のすべてのトラフィックは停止するが接続されたままになり、NIC LEDに通信が表示されます。これは継続的な問題であり、週に2〜3回クロップし続けましたが、稼働時間は約12〜13時間でした（サーバーは毎晩再起動されます）。

NetbalancerServiceサービスを（好奇心から）終了しようとした後、Seriousbit Netbalancerが原因であることがわかりました。その後、トラフィックがインターフェイスを通過し始めました。Netbalancerをアンインストールしました。

Asus Mainboard lanでも同じ問題が発生しました。Realtek Webサイトから最新のドライバーをインストールすることで修正されました