最近、クラウド プロバイダーのクラウドで実行されている一部の Windows VM の ARP テーブルに、誤った MAC アドレスが入力されるという問題が発生しています。たとえば、10.1.2.3 に ping すると、一部の Windows VM には、他の大多数の VM とは異なる MAC アドレスが表示されます。その結果、これらの少数の Windows VM は 10.1.2.3 に到達できませんが、残りの VM (Windows と Linux の両方) は到達できます。
パケットキャプチャを実行した後、誤ったMACアドレスの原因は、次のものに含まれるMS-NLB-PhysServer-XX_であるようです。Wiresharkの公開リストただし、私は MS-NLB を一切実行していないため、そのソースが何なのかが非常にわかりにくいです。私のクラウド プロバイダーは、そのソースはプロバイダーから来ていないと言っています。私の質問は次のとおりです。
- そのデバイスを所有していない場合、MAC アドレスに基づいてソース デバイスを識別する良い方法はありますか? つまり、それがクラウド プロバイダーのロード バランサーから来ているかどうかが疑問です。
- このソース デバイスが他のデバイスに送信する MAC アドレスが間違っている理由は何ですか? つまり、10.1.2.3 やその他の新しく作成されたネットワーク インターフェイスの MAC アドレスが間違っているのはなぜですか?
- VM のサブセットのみがこのソースから不正な MAC アドレスを取得し、同じサブネット内の他の VM が他のソースから適切な MAC アドレスを取得する理由は何ですか?
答え1
私たちもこれに遭遇しました。これは、EKS Windows ノードの再起動後に発生しています。GMSA のドメインに参加するノードがあり、再起動が必要なので、これらのインスタンスではすぐに問題が発生しました。
サポートチケットを開き、彼らが提供した回避策はシャットダウンスクリプトで以下を実行することでした。
powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit
この出口は、一定期間のシャットダウンの停止を防ぐため重要であると言われました。
私はこの回答をこのプロセスを自動化するための基礎として使用しました -https://stackoverflow.com/a/47709154
答え2
他のデバイスを所有していない場合は、完全に異なるネットワーク上にあるため、そのデバイスの MAC アドレスは表示されず、トラフィックを他の最終デバイスにルーティングする最も近いデバイスの MAC アドレスが表示されると考えられます。
エンドツーエンドの通信はデータリンク層 (つまりレイヤー 2) では行われないことに留意してください。
ここで最も可能性が高いシナリオは、ルーティングが誤って設定されていることです。いくつかのクラウド プロバイダーのネットワーク ルート テーブルではなく、VM と OS レベルで... または、異なるネットワーク (おそらく AWS サブネット?) にあり、異なるルート テーブルを持っています。
答え3
これも回答として追加します。
いくつかのクラウドプロバイダーはとてもネットワークに対する独特な見方をしており、ネットワークの専門家がとんでもないと思うような方法でそれを処理しています。しかし、これが彼らのやり方であり、私たちはそれに対処するしかありません。
Azure では、MAC アドレスはまったく意味をなしません。すべての ARP テーブル エントリは常に を指します12-34-56-78-9a-bc。これは、Azure ネットワークはすべて IP レイヤーで処理され、ARP は存在しないかまったく機能しないためです。Azure VM は、単に「この IP アドレスがあります」(別名「Gratuitous ARP」) と叫ぶことはできません。これは、Azure プラットフォームがトラフィックをその VM にルーティングするためにその IP アドレスを認識する必要があるためです。Azure クラスタリングは非常に奇妙な方法で動作するため、クラスターの前に非常に珍しいロード バランサーを配置する必要があります。
正直、これが AWS でどのように機能するかはわかりませんが、同じくらい奇妙、あるいはそれ以上に奇妙だと思います。