S10506X‑G 虚拟机热迁移 MAC/ARP 表项不同步问题解析

组网背景：S10506X‑G 核心，下挂多组 M‑LAG 接入交换机；VM 虚拟机跨不同接入设备热迁移；现象：MAC 地址已经学习到新聚合出接口，但三层 ARP 表项的出接口还保留旧聚合口，跨网段流量继续往旧端口转发，造成业务异常H3C。

问题 1：10506X‑G 默认是否 MAC 迁移后立即同步 ARP？

默认不开启。

• MAC 地址表：收到源 MAC 报文后会立刻更新出接口；
• ARP 表（三层网关表项）：默认不会跟随 MAC 表变化同步更新出接口，要等待 ARP 老化探测周期（默认 20 分钟）才会刷新，这就是你现场遇到的故障根源H3C。
• 需要手动全局开启命令：

作用：当同一 VLAN 内 MAC 地址发生迁移（出接口改变），立刻同步刷新动态 ARP 表项的出接口；静态 ARP 不受该命令影响H3C。

问题 2：生产环境长期开启mac‑address mac‑move fast‑update是否可行？

你的现状：服务器迁移为主，二层广播风暴极少。

✅满足条件下可以长期开启，适合虚拟化数据中心网关场景：

1. 该功能本身性能开销很小；风险主要来自二层环路引发的频繁 MAC 漂移：如果网络存在环路，MAC 反复在多个端口来回漂移，该命令会频繁刷新 ARP 表项，带来 CPU 轻微波动。
2. 防护配套建议（必须配套，规避环路风险）：

只要display mac‑address mac‑move没有大量持续漂移记录，就代表网络无环路，该命令长期运行安全稳定。

⚠️注意限制：

1. 该功能只对同一 IRF 成员板卡内发生的 MAC 迁移生效；跨不同板卡的 MAC 迁移，部分版本该功能不生效，要依赖 VM 发出的免费 ARP/GARP 刷新 ARP 表项H3C。
2. 只处理动态 ARP，静态 ARP 不会被更新。

问题 3：mac‑address mac‑move fast‑update + 虚拟机发送免费 ARP，二者配合方案

两个机制是互补，不是二选一，建议同时部署：

1. 虚拟化侧优先：VM 迁移完成发送 GARP / 免费 ARP（vMotion/KVM 热迁移标配）
   • 虚拟机迁移完成，主动广播免费 ARP，上游 M‑LAG 接入、核心 10506X‑G 收到 GARP，直接刷新 MAC+ARP；
   • 即使跨板卡迁移导致mac‑address mac‑move fast‑update失效，GARP 依然可以修复 ARP 表项。
   • 虚拟化平台配置：开启迁移后发送免费 ARP，部分 Linux 虚拟机内核参数net.ipv4.conf.all.arp_notify = 1。
2. 核心交换机开启mac‑address mac‑move fast‑update
   • 作为兜底防护：万一 GARP 报文丢包（丢包是客观存在的），当 VM 有业务流量从新端口发出触发 MAC 迁移，交换机立刻同步刷新 ARP 出接口，避免长时间黑洞。

补充排错 & 优化要点

1. M‑LAG 环境下注意：接入 M‑LAG peer‑link 链路不能过滤 GARP / 免费 ARP，否则迁移通告报文被丢弃。
2. 查看表项确认故障现象：

对比两条输出，观察 MAC 表出接口与 ARP 表出接口是否不一致，就是典型故障现象。 3. 不要调小 ARP 全局老化时间作为主要解决方案：会增大 ARP 广播压力，不推荐。

简短总结

1. S10506X‑G默认 MAC 迁移不会自动刷新 ARP 表项，需要mac‑address mac‑move fast‑update开启该能力。
2. 你的场景（以 VM 迁移为主、极少广播风暴）可以长期开启；配套 MAC 漂移告警日志，及时发现二层环路风险。
3. mac‑move fast‑update是兜底手段，不能替代虚拟机迁移发送 GARP 免费 ARP，二者配合，一个虚拟机侧主动通告，一个核心交换机侧流量触发兜底刷新，最大限度消除迁移后 ARP 出接口残留旧端口问题。
4. 注意：跨 IRF 不同板卡 MAC 迁移时 fast‑update 存在局限性，GARP 免费 ARP 依然是最可靠机制。