m-lag lacp

你描述的场景是 MLAG 双交换机配置为独立运行模式 + LACP System ID 保持一致，然后模拟 peer-link 和 keepalive 同时断开 的情况下，Linux 服务器和 Windows Server 上表现不一致，Linux 端口被正确 unselect，而 Windows Server 的聚合组成员却仍然全选中。

✅ 简单结论：

是的，这种情况下极有可能是 Windows Server 的 LACP 实现机制或网卡驱动的问题。

📌 背景解析

在 MLAG 场景中，两个交换机使用：

• Peer-link：用于数据同步（MAC表、ARP、转发表）

• Keepalive 链路：用于检测对方是否还在线

若两条链路都断掉，MLAG 状态会进入 Split-brain（脑裂）状态，此时双方交换机都以为对方挂了，都会认为自己是主用设备，继续对下提供服务。

为了避免双主冲突，LACP 协议应当使某些链路 unselect。

✅ Linux 和 Windows 行为对比

重点问题：

• Windows NIC Teaming（特别是默认配置下）对于 partner 信息处理有延迟，或不主动检测 partner 的 LACP 协议状态；

• 某些 Windows Server teaming 模式是 静态（Static）聚合 而不是真正的 LACP 动态聚合，不响应对端异常；

• 网卡厂商的驱动和 teaming 实现也不一样（如 Intel ANS、Broadcom BASP、Microsoft Native）。

✅ 建议排查步骤

1. 确认 Windows Server 上的聚合类型

在 PowerShell 执行：

检查是否为 LACP 模式：

如果是 Static 模式，那肯定无法自动识别脑裂异常。

2. 观察聚合状态

在 Windows 上查看每个成员端口的状态：

看 Status 是否仍然为 Up，如果是，说明驱动没有意识到对端状态异常。

3. 优化建议

🛠️ 拓展优化建议

为了提升稳定性，可在交换机侧开启：

并建议开启 MLAG 的 errdisable 保护机制（防止脑裂时误判）：

✅ 总结

你遇到的问题确实很可能是 Windows Server 网卡 Teaming 对 LACP 状态不敏感所致，建议你：

• 确认使用的是 LACP 模式

• 启用快速 LACP 检测

• 选择更稳定的网卡驱动或使用 Intel ANS

如果你能提供：

• Windows Server 的版本

• Teaming 设置截图或命令输出

• 网卡型号及驱动版本