目前，我们正在VM主机上为我们的NIC团队使用“链接状态”，但最近遇到了两个交换机中有一个发生内存错误并停止传输stream量的问题。 我们所有的VM主机都closures了，大部分客户（已经使用这个path）也停止响应，直到我们手动closures这个开关。
在Linux绑定环境中，可以使用arp_intervals作为检测链接状态的另一种方式，但在VMWare中只有Beacon探测。 BP不同于arp_interval，因为您不select主机来testing连通性，以及您需要三个或更多的接口来执行此操作。
我们所有的VM主机都有四块网卡，所以这三块网卡的要求不应该太麻烦。 但是，虽然文档仅指出至less需要三个独立的物理网卡（pNIC），但每个示例还有三个独立的物理交换机，但没有说明这是否也是必需的。 正如我所寻找的答案，我遇到了这个博客，其中指出：
“如果vSwitch中的多个pNIC连接到同一个pSwitch，请勿使用信标探测，这可能会导致在pSwitch的两个或多个端口上出现相同的MAC地址，这是”非常糟糕的事情“”
在我们的configuration中，我们没有三个交换机来增加这个问题，在我的一些初步testing中，我遇到了无法解释的链路振荡问题，这些问题可能与它们被插入同一个交换机相关。
那么三个独立的物理交换机是否也是信标探测的要求？ 我只能将我的configuration链接到状态？ 而且，从修辞的angular度来说，他们为什么不把arp_interval作为他们网卡绑定的一个选项呢？
使用信标探测是build议使用至less3个pNICs，因为这是信标工作最好的方式。 ESXi从物理NIC卡中发出广播包。 同一vSwitch内的其他pNIC将等待，看看是否收到来自其他pNIC的数据包。 无论pNIC没有收到广播，ESXi都会认为它是下行链路。
将所有3个pNIC连接到相同的交换机并使用信标探测，当链路状态起作用时会浪费资源，因为它更简单。 链接是打开还是closures？ configuration问题（STP或端口块）不会显示链接状态。
信标探测的目的和devise是将pNIC连接到不同的pSwitch，因为它用于“testing”下游交换机; 交换机超出了pNIC所附带的交换机。 BP可以确定是否说下游iSCSI SAN的第三个pSwitch发生故障，链路状态不会检测到，但是BP应该。 然后ESXi服务器可以确定要执行的操作。 即使链路状态不可用，链路状态仍将继续尝试将数据包发送到SAN。