我们目前在 VM 主机上为我们的 NIC 团队使用仅链接状态，但最近遇到了一个问题，即我们的两个交换机之一出现内存错误并停止传递流量。我们所有的 VM 主机都宕机了，大多数来宾（已经在使用该路径）也停止响应，直到我们手动关闭该开关。
在 Linux 绑定环境中，您可以使用 arp_intervals 作为另一种检测链路状态的方法，但在 VMWare 中只有 Beacon Probing。BP 与 arp_interval 的不同之处在于您不选择要测试连接的主机，而且您需要三个或更多接口来执行此操作。
我们所有的 VM 主机都有四个 NIC，因此三个 NIC 的要求应该不会太麻烦。然而，虽然文档只说明至少需要三个独立的物理 NIC (pNIC)，但每个示例也有三个独立的物理交换机，并且没有说明这是否也是一个要求。当我寻找这个问题的答案时，我看到了这个博客，其中指出：
“如果 vSwitch 中的多个 pNIC 连接到同一个 pSwitch，则不要使用 Beacon Probing。这可能会导致相同的 MAC 地址出现在 pSwitch 上的两个或多个端口上，这是“一件非常糟糕的事情””
我们的配置中没有三个交换机来增加这个问题，在我的一些初步测试中，我遇到了无法解释的链路抖动问题，这些问题可能与它们被插入同一个交换机有关。
那么三个独立的物理开关是否也是信标探测的要求？我是否仅针对我的配置降级为链接状态？而且，半修辞地说，他们为什么不将 arp_interval 作为其 NIC 组合中的一个选项？
对于信标探测，建议使用至少 3 个 pNIC，因为这是信标的最佳工作方式。ESXi 从物理 NIC 卡发出广播数据包。同一 vSwitch 中的其他 pNIC 然后等待查看它们是否收到来自其他 pNIC 的数据包。无论哪个 pNIC 没有收到广播，ESXi 都会假定它是下行链路。
将所有 3 个 pNIC 连接到同一个交换机并使用信标探测是一种资源浪费，因为它更简单。链接是打开还是关闭？配置问题（STP 或端口块）不会显示链接状态。
信标探测的目的和设计是将 pNIC 连接到不同的 pSwitch，因为它用于“测试”下游交换机；交换机超出了 pNIC 所连接的交换机。BP 可以确定 iSCSI SAN 下游的第 3 个 pSwitch 是否发生故障，链路状态不会检测到它，但 BP 应该。然后 ESXi 服务器可以确定它想要做什么。链接状态将继续尝试向 SAN 发送数据包，即使它不可用。