對 NIC 小組進行疑難排解

適用于: Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI、21H2 和20H2 版本

在本主題中,我們將討論針對 NIC 小組進行疑難排解的方法,例如硬體和實體交換器的安全性。 當標準通訊協定的硬體符合規範時,可能會影響 NIC 小組的效能。 此外,根據設定,NIC 小組可能會從相同 IP 位址傳送封包,其中包含可在實體交換器上傳送安全性功能的多個 MAC 位址。

不符合規格的硬體

在正常操作期間,NIC 小組可能會從相同的 IP 位址傳送封包,但有多個 MAC 位址。 根據通訊協定標準,這些封包的接收者必須將主機或 VM 的 IP 位址解析為特定的 MAC 位址,而不是回應接收封包中的 MAC 位址。 使用正確的目的地 MAC 位址(也就是擁有該 IP 位址的 VM 或主機的 MAC 位址)傳送封包的用戶端,會將位址解析通訊協定正確地 (ARP 和 NDP) 傳送封包。

某些 embedded 硬體無法正確地執行位址解析通訊協定,也可能不會使用 ARP 或 NDP 明確地將 IP 位址解析為 MAC 位址。 例如,存放區域網路 (SAN) 控制器可能會以這種方式執行。 不符合規範的裝置會從接收的封包複製來源 MAC 位址,然後在對應的傳出封包中使用該位址做為目的地 MAC 位址,這會導致封包傳送至錯誤的目的地 MAC 位址。 因此,Hyper-v 虛擬交換器會捨棄封包,因為它們不符合任何已知的目的地。

如果您在連線到 SAN 控制器或其他內嵌硬體時遇到問題,您應該採取封包捕獲,以判斷您的硬體是否正確實施 ARP 或 NDP,並洽詢您的硬體廠商以取得支援。

實體交換器安全性功能

視設定而定,NIC 小組可能會從相同 IP 位址傳送封包,並將實體交換器上的安全性功能提供給多個來源 MAC 位址。 例如,動態 ARP 檢查或 IP 來源防護,特別是當實體交換器不知道埠是否為小組的一部分時,這會在您以交換器獨立模式設定 NIC 小組時發生。 檢查交換器記錄檔,以判斷交換器安全性功能是否造成連線問題。

使用 Windows PowerShell 來停用和啟用網路介面卡

NIC 小組失敗的常見原因是在執行一連串命令時,小組介面已停用,而且在許多情況下都有意外。 此特定的命令順序不會啟用所有 NetAdapters 停用,因為停用所有 Nic 的基礎實體成員會移除 NIC 小組介面。

在此情況下,NIC 小組介面不再顯示于 Get-netadapter 中,因此, 啟用-get-netadapter \* 並不會啟用 NIC 小組。 不過, get-netadapter \* 命令確實會啟用成員 nic,然後在短時間之後 (,) 重新建立小組介面。 小組介面會維持「停用」狀態,直到重新啟用為止,讓網路流量開始流動。

下列 Windows PowerShell 的命令順序可能會意外停用 team 介面:

Disable-NetAdapter *
Enable-NetAdapter *
  • NIC小組:在本主題中,我們會概述 Windows Server 2016 中 (NIC) 小組的網路介面卡。 NIC 小組可讓您將32一或多個實體 Ethernet 網路介面卡分組成一或多個以軟體為基礎的虛擬網路介面卡。 如果網路介面卡失敗,這些虛擬網路介面卡可提供快速的效能和容錯功能。

  • NIC 小組 MAC 位址使用和管理:當您設定具有交換器獨立模式的 NIC 小組,以及位址雜湊或動態負載散發時,小組會使用輸出流量上主要 NIC 小組成員的媒體存取控制 (MAC) 位址。 主要 NIC 小組成員是作業系統從一組初始小組成員中選取的網路介面卡。

  • Nic 小組設定:在此主題中,我們將概述 NIC 小組屬性,例如小組和負載平衡模式。 此外,我們也會提供待命介面卡設定和主要小組介面屬性的詳細資料。 如果 NIC 小組中至少有兩張網路介面卡,您就不需要指定待命介面卡來容錯。