我正在尝试解决客户网络上的服务器问题。我们不支持该网络基础设施。
例如，我在故障转移群集中有 2 个节点（WS2019）。每个节点都有 2 个网卡，并连接到 swt 1 和 swt 2 以实现容错。节点的网卡以交换机独立动态模式连接到 NIC Teaming。虚拟机使用外部网卡连接到网络。
当我将虚拟机（WS2019）迁移到另一个节点时，我在交换机上收到一个错误：sw_matm-4-macflap_notif，其中包含实时迁移到不同节点的虚拟机的 MAC 地址和发生 MAC 地址抖动的端口。
我无法找到问题所在并排除故障。
有什么信息可以帮助我解决我遇到的问题吗？
答案1
我觉得这种行为对于独立于交换机的组合模式来说是正常的并且是预料之中的。
根据Microsoft 文档：
在交换机独立模式下，NIC 团队成员所连接的交换机不知道 NIC 团队的存在，也无法确定如何将网络流量分配给 NIC 团队成员 - 相反，NIC 团队会在 NIC 团队成员之间分配入站网络流量。
它如何执行分发？它将目标的 VM 发送出口通过相应的团队成员发送（传出）数据包，希望交换机看到其 MAC 地址并了解它位于团队成员所连接的端口上。然后，指向该 MAC 地址的回复数据包将通过该端口进入 VM。但是，Hyper-V 还会进行某种形式的负载平衡：
当您使用具有动态分配的交换机独立模式时，网络流量负载将根据动态负载平衡算法修改的 TCP 端口地址哈希进行分配。动态负载平衡算法会重新分配流量以优化团队成员带宽利用率，以便单个流量传输可以从一个活跃团队成员移动到另一个成员。
即，有时 MAC 可能会在该端口上消失，并出现在另一个团队成员所连接的端口上，以释放前一个端口以用于其他流量（因此，此 VM 正在从这个过载端口“平衡”到负载较少的端口）。网络确实将其视为“MAC 地址抖动”，因为 VM 的 MAC 地址在其主机节点的 NIC 团队成员所连接的端口集之间来回移动。
在迁移过程中，节点之间的 MAC 可能会出现短暂的“波动”，之后情况就会稳定下来。当 VM 最终在节点上运行时，其 MAC 会开始在新节点 NIC 连接的端口之间浮动。
可以通过禁用负载平衡来禁用团队成员之间的移动。迁移时，移动到另一组端口是不可避免的。
管理存在群集的网络的网络工程师必须了解此功能。如果不希望出现这种情况，则解决此问题的正确方法是使用支持群集的可堆叠交换机，并正确配置交换机受抚养人团队模式。