目前，我們僅對 VM 主機上的 NIC 團隊使用“鏈路狀態”，但最近遇到了一個問題，即我們的兩個交換器之一出現記憶體錯誤並停止傳遞流量。我們所有的虛擬機器主機都宕機了，大多數來賓（已經使用該路徑的）也停止回應，直到我們手動關閉該開關。
在Linux綁定環境中，您可以使用arp_intervals作為偵測連結狀態的另一種方法，但在VMWare中只有Beacon Probing。 BP 與 arp_interval 不同，因為您不選擇要測試連接的主機，並且需要三個或更多介面來執行此操作。
我們所有的 VM 主機都有四個 NIC，因此三個 NIC 要求應該不會太麻煩。但是，雖然文件僅指出至少需要三個獨立的實體 NIC (pNIC)，但每個範例還具有三個獨立的實體交換機，並且沒有說明這是否也是一個要求。當我尋找這個問題的答案時，我發現這部落格指出：
「如果vSwitch 中的多個pNIC 連接到同一個pSwitch，請勿使用信標探測。這可能會導致pSwitch 上的兩個或多個連接埠上出現相同的MAC 位址，這是「一件非常糟糕的事情」
我們的配置中沒有三個交換器來增加這個問題，並且在我的一些初步測試中，我遇到了無法解釋的鏈路抖動問題，這可能與它們插入同一交換器有關。
那麼信標探測也需要三個獨立的物理交換器嗎？我是否僅因我的配置而被降級為連結狀態？而且，半言而喻的是，為什麼他們在 NIC 分組中不將 arp_interval 作為一個選項？
答案1
對於信標探測，建議至少使用 3 個 pNIC，因為這是信標運作得最好的方式。 ESXi 從實體網路卡發出廣播封包。然後，同一 vSwitch 內的其他 pNIC 等待查看是否收到其他 pNIC 的資料包。無論哪個 pNIC 未收到廣播，ESXi 都會假設它是下行鏈路。
當連結狀態有效時，將所有 3 個 pNIC 連接到同一交換器並使用信標探測會浪費資源，因為它更簡單。連結是開啟還是關閉？配置問題（STP 或連接埠區塊）不會隨鏈路狀態一起顯示。
信標探測的目的和設計是將 pNIC 連接到不同的 pSwitch，因為它用於「測試」下游交換器；交換器超出了 pNIC 所連接的交換器。 BP 可以確定 iSCSI SAN 下游的第三個 pSwitch 是否發生故障，連結狀態不會偵測到它，但 BP 應該會偵測到。然後 ESXi 伺服器可以確定它想要執行的操作。即使 SAN 不可用，連結狀態也會繼續嘗試將封包傳送到 SAN。