M-lag+VM虚拟机迁移

1. 为什么交换机 A 没有立即将 MAC 出接口改为 Peer-Link？（场景一分析）

正常流程应该是：
VM 迁移到节点 2（连交换机 B） -> 交换机 B 从下行 Access 口学到 VM MAC -> 交换机 B 通过 Peer-Link 发送 MAC Sync Message 给交换机 A -> 交换机 A 收到消息，将本地 MAC 表的出接口修改为 Peer-Link（表示去对面找） -> 此时核心 A 的回程流量到达交换机 A，交换机 A 从 Peer-Link 转发给交换机 B，B 发给 VM。

异常原因分析（为什么会有 12 秒黑洞）：
你观察到的“12秒”是一个非常关键的线索。在标准实现中，MAC 同步是实时的。出现 12 秒延迟通常有以下几种可能：

• MAC 同步报文丢失/重传： 交换机 B 发出了同步报文，但交换机 A 没收到。交换机 B 可能在后台进行了重试。如果 Peer-Link 链路存在微突发拥塞，或者控制报文优先级设置不当，可能导致控制报文排队。
• CPU 处理延迟： 如果交换机 A 的 CPU 负载极高，处理 M-LAG 控制报文的队列可能被阻塞。
• MAC 防环/保护机制： 某些版本中，如果交换机 A 认为自己是该 MAC 的“Owner”（尽管 Access 端口通常是非 Owner），或者为了防止 MAC 震荡，可能会延迟更新。
• Bug 或特性限制： 在较旧的软件版本中，Access 端口（单挂）的 MAC 同步机制不如 Eth-Trunk 稳定，可能存在同步延迟较大的已知缺陷。

验证方法：
在交换机 A 和 B 上执行 display m-lag mac-sync statistics。查看是否有 Sync Message Send Fail 或 Drop 计数增加。

2. 跨组迁移（AB -> CD）为什么会丢包？（场景二分析）

问题分析：
这是一个典型的核心间 MAC 不同步导致的问题。

• 当前状态： VM 从 AB 迁到了 CD。
• 核心 A 的行为： 核心 A 收到了来自 CD 组（经过 C/D 交换机）的流量，因此核心 A 更新了 MAC 表：VM_MAC -> Out: Peer-Link (指向 C/D)。这是正确的。
• 核心 B 的行为： 核心 B 没有收到来自 CD 组的流量（因为流量哈希到了核心 A）。核心 B 的 MAC 表中，VM_MAC 依然指向 Peer-Link (指向 A/B) 或者表项已老化但未刷新。
• 丢包过程：
  1. 外部 PC 发包，哈希到了 核心 B。
  2. 核心 B 查 MAC 表，发现 VM_MAC 在 AB 组（因为它不知道 VM 去了 CD）。
  3. 核心 B 将流量发给 交换机 AB 组。
  4. 交换机 AB 组收到流量，发现 VM 已经不在了（VM 在 CD），或者发现出接口和入接口相同（如果是直连丢弃），导致黑洞。

为什么核心 A 没同步给核心 B？
核心 A 和核心 B 之间也是 M-LAG 关系（通常称为 Core-M-LAG）。当核心 A 学到新 MAC（指向 CD）时，它必须通过核心间的 Peer-Link 把这个 MAC 同步给核心 B。
如果核心 B 没更新，说明核心间的 MAC 同步失败了。

3. & 4. M-LAG MAC 同步是实时的吗？如何强制立即同步？

• 官方文档 vs 实际实现： 官方文档说“实时同步”，指的是控制平面的信令交互是实时的（一旦触发，立即发报文）。但在数据平面，受限于硬件转发表项更新速度和软件处理队列，可能会有微小的延迟（通常 < 1秒）。
• 关于 30 秒： 你看到的 display m-lag drcp stat in br 中的 30 秒是 DLS (Dynamic Link State) 或 DRCP 的状态同步周期，用于检测链路状态和选举主备，这与 MAC 地址表项同步无关。MAC 同步是独立的过程。
• 如何优化/强制同步：
  • 检查配置： 确保两端都开启了 MAC 同步功能（默认通常是开启的）：[Switch] m-lag mac-sync enable
  • VM 侧行为： 你提到了“VM 侧勾选了通告交换机”。这非常重要。VM 迁移后发送 GARP (Gratuitous ARP)。
    • 如果 VM 发送了 GARP，交换机 B 会刷新 MAC 表，并触发向 A 的同步。
    • 建议： 在 VM 迁移脚本中，确保在迁移完成后，显式发送一次 GARP 广播，或者在宿主机上触发网络重置，以加速 MAC 同步。
  • 调整同步策略（如果支持）： 某些新版本支持调整 MAC 同步的批量大小或优先级，但这通常需要联系厂商技术支持获取特定补丁。

5. 上述反馈的丢包情况是否符合转发常理？

• 瞬时丢包（1-3个包）： 符合常理。任何二层移动（无论是 VM 迁移、网线重插）都会导致短暂的 MAC 学习和同步过程，这期间会有丢包。
• 12 秒黑洞 / 跨组黑洞： 不符合常理。这属于故障或配置/版本缺陷。在成熟的 M-LAG 部署中，MAC 同步应该在几百毫秒内完成，绝不应超过 1 秒。

建议排查步骤

1. 抓包分析（最关键）：

   • 在 Peer-Link 链路上抓包。
   • 过滤 M-LAG 控制报文（通常是 EtherType 0x894F 或类似的私有协议，具体看 H3C 定义）。
   • 观察：当 VM 迁移并发 Ping 时，交换机 B 是否发出了 MAC Sync Request？交换机 A 是否回复了 ACK？
   • 如果 B 发了但 A 没回，或者 A 回了但没更新表项，这就是证据。

2. 检查 MAC 同步统计：

   • 在核心 A、B 和接入 A、B 上执行 display m-lag mac-sync statistics。
   • 关注 Total Sync Messages 和 Failed Messages。

3. 检查软件版本：

   • 105XG 和 6526XE 的 Comware 版本可能存在已知的 MAC 同步 Bug。建议查阅 Release Notes，寻找关于 "M-LAG MAC sync delay" 或 "Access port MAC sync" 的修复记录。

4. 临时规避方案（治标不治本）：

   • 如果无法立即升级版本，可以尝试在核心交换机上调整 mac-address aging-time（虽然这主要影响老化管理，不直接影响同步延迟）。
   • 确保 VM 侧的“迁移后通告”功能正常工作，并且 VM 网卡驱动支持快速 GARP。