最近，我遇到了以下問題：在雲端供應商的雲端中執行的某些 Windows 虛擬機器的 arp 表中填入了不正確的 MAC 位址。例如，如果我 ping 10.1.2.3，某些 Windows 虛擬機會顯示與大多數其他虛擬機器不同的 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 位址錯誤？
- 為什麼只有一部分虛擬機器從該來源取得錯誤的 MAC 位址，而同一子網路中的其他虛擬機器卻從其他來源取得良好的 MAC 位址？
答案1
我們也遇到了這個問題，它發生在我們的 EKS Windows 節點重新啟動後。我們有加入 GMSA 域的節點，這需要重新啟動，因此這些實例立即發現了這個問題。
我開了一張支援票，他們提供的解決方法是讓關閉腳本執行以下命令
powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit
據說退出很重要，因為它可以防止關閉一段時間後掛起。
我用這個答案作為自動化這個過程的基礎 -https://stackoverflow.com/a/47709154
答案2
If you don't own the other device I'm assuming it's because it's on a wholly different network which would mean you won't see its MAC address but the one on the device closest to you that will route the traffic to that other final裝置.
請記住，端對端通訊不會發生在資料鏈結層（即第 2 層）。
這裡最可能的情況可能是您的路由設定不正確一些您的虛擬機器和作業系統層級而不是您的雲端供應商的網路路由表...或它們位於不同的網路（可能是 AWS 子網路？）並且具有不同的路由表。
答案3
也將其添加為問題。
一些雲端提供者擁有相當對網路的獨特看法，並以網路專業人士認為令人無法容忍的方式處理它；然而，這就是他們的工作方式，我們必須面對它。
在 Azure 中，MAC 位址沒有任何意義；所有 ARP 表格條目始終指向12-34-56-78-9a-bc，因為所有 Azure 網路都是在 IP 層處理的，且 ARP 不存在或根本不工作； Azure VM 不能簡單地大喊「我有這個 IP 位址」（又稱為「免費 ARP」），因為 Azure 平台需要了解它才能將流量路由到該 VM。 Azure 叢集的工作方式非常奇怪，您必須在叢集前面放置一個非常不尋常的負載平衡器。
老實說，我不知道這在 AWS 中是如何運作的，但我想這即使不是更糟，也很奇怪。