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