M-lag+VM虚拟机迁移
- 0关注
- 0收藏，149浏览
问题描述：
组网：
1、组网如图所示，核心设备M-lag双活组网，三层连接外部网络至测试PC，核心下挂多组m-lag组网二层接入。接入与核心直接采用m-lag DR聚合接口互联。
2、交换机AB为一组、CD为一组。所有交换机连接VM接口均为ACCESS 单挂、非DR-LACP聚合。VM节点出接口偏向主备（基于虚拟机类型，意思虚拟机只会选一个物理出口）
问题：
1、VM上虚拟机从VM节点1迁移到VM节点2时属于同一组leaf迁移。此时有两种现象：
1）虚拟机迁移到VM2节点后还从连接交换机A的接口发出ping网关报文时，流量正常，链路对应图中VM2节点左线（偶尔丢1一个包属正常）
2）虚拟机迁移到VM2节点后切换到连接B交换机的接口外发流量就有概率发生丢包情况（最多丢弃12个包），逻辑梳理：
虚拟机迁移后回发送ping报文，交换机B根据icmp数据更新本地mac地址表入口，并将数据包转发给网关，网关回程流量回哈希到交换机A，此时就概率出问题了（交换机A观察发现没有在交换机B将虚拟机的MAC更新出接口为交换机B自身下行物理接口后，将MAC出接口改为peer-link的聚合口，还保留为交换机A自身的物理下联口，属于AB交换机对于这个MAC都有自己独立的物理出接口，此时网关回程流量哈希到交换机A就会导致报文“黑洞”，哈希到交换机B就可以正常转发，因为交换机B的MAC出接口是迁移后真实的。这个状态观察最久持续12秒（流量黑洞12秒、丢了13个包），交换机A未切换MAC出接口为peer-link口的原因为？ 猜测交换机B在本地通过虚拟机迁移后持续发出的ping 网关的icmp流量更新本地mac表出接口后没有立即同步给m-lag邻居，导致交换机A接收到哈希的流量不走peer-link横向转发、而是本地物理接口直接转发丢弃。同时观察交换机mac迁移时的时间是否和交换机上display m-lag drcp statist inter br 聚合口命令查看到的drcp最近一次同步时间类型？ 这个同步会同步表项更新交换机A的MAC出接口，这样网关回程流量到了交换机A就可以横向转发？？？）
2、虚拟机从AB交换机组迁移到CD交换机组时，外部测试设备ping虚拟机时也会概率产生丢包：
1）对于核心交换机来说虚拟机从AB迁移到CD后，就是一次MAC迁移（从聚合组A迁移到聚合组B），但此时虚拟机迁移后的数据包哈希发送到了交换机C然后发给了核心A，核心A就会更新MAC地址表入接口由聚合组A 到聚合组B（对于CD交换机组），此时设备回包到C到终端。
2）外部测试PC的流量如果哈希负载到核心B，核心B发现目的MAC为自己上行接口、解析报文二三层、根据三层IP查询路由表、ARP表、MAC表，此时核心B把去往虚拟机的流量发给了交换机AB组设备（核心B没有从核心A同步MAC表？ 且核心105XG是根据MAC表转发流量的），此时流量到了AB交换机，AB交换机发现该数据包的出接口和收到数据包的接口是相同的就会丢弃、造成黑洞，且上游设备一般根据流负载、就会一直丢）
3）如果外部流量哈希到了核心A，核心A由于前面已经收到虚拟机迁移后流量进行了MAC更新，所以可以正常转发到交换机C到终端，终端的数据包即使发给核心B，核心B也是查询路由表转发到外部，这个情况下没什么异常？？？
3、M-lag情况下单挂接口MAC更新后会将MAC表项立即同步给m-lag邻居吗？ 我看交换机display m-lag drcp stat in br 聚合口 发现30秒发一次表项同步？？？
4、有没有办法让M-lag设备A更新任意mac表项后立即同步给m-lag邻居（官方文档里面写的m-lag mac是实时同步、MAC更新后立即同步）
5、我上述反馈的丢包情况是否复核转发常理
6、核心为105X-G、接入为6526XE
7、VM侧勾选了迁移后“通告交换机”功能
- 2026-09-15提问
- 举报
-
(0)
最佳答案
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)或者表项已老化但未刷新。 - 丢包过程：
- 外部 PC 发包，哈希到了 核心 B。
- 核心 B 查 MAC 表，发现
VM_MAC在 AB 组（因为它不知道 VM 去了 CD）。 - 核心 B 将流量发给 交换机 AB 组。
- 交换机 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 同步的批量大小或优先级，但这通常需要联系厂商技术支持获取特定补丁。
- 检查配置： 确保两端都开启了 MAC 同步功能（默认通常是开启的）：
5. 上述反馈的丢包情况是否符合转发常理？
- 瞬时丢包（1-3个包）： 符合常理。任何二层移动（无论是 VM 迁移、网线重插）都会导致短暂的 MAC 学习和同步过程，这期间会有丢包。
- 12 秒黑洞 / 跨组黑洞： 不符合常理。这属于故障或配置/版本缺陷。在成熟的 M-LAG 部署中，MAC 同步应该在几百毫秒内完成，绝不应超过 1 秒。
建议排查步骤
抓包分析（最关键）：
- 在 Peer-Link 链路上抓包。
- 过滤 M-LAG 控制报文（通常是 EtherType 0x894F 或类似的私有协议，具体看 H3C 定义）。
- 观察：当 VM 迁移并发 Ping 时，交换机 B 是否发出了
MAC Sync Request？交换机 A 是否回复了ACK？ - 如果 B 发了但 A 没回，或者 A 回了但没更新表项，这就是证据。
检查 MAC 同步统计：
- 在核心 A、B 和接入 A、B 上执行
display m-lag mac-sync statistics。 - 关注
Total Sync Messages和Failed Messages。
- 在核心 A、B 和接入 A、B 上执行
检查软件版本：
- 105XG 和 6526XE 的 Comware 版本可能存在已知的 MAC 同步 Bug。建议查阅 Release Notes，寻找关于 "M-LAG MAC sync delay" 或 "Access port MAC sync" 的修复记录。
临时规避方案（治标不治本）：
- 如果无法立即升级版本，可以尝试在核心交换机上调整
mac-address aging-time（虽然这主要影响老化管理，不直接影响同步延迟）。 - 确保 VM 侧的“迁移后通告”功能正常工作，并且 VM 网卡驱动支持快速 GARP。
- 如果无法立即升级版本，可以尝试在核心交换机上调整
- 2026-09-15回答
- 评论(0)
- 举报
-
(0)
核心就六句话：
- 同组 leaf 迁移的 12s 黑洞根因：AB 是 M-LAG 双活，但单挂 Access 口学到的 MAC默认不会实时同步给对端。VM 切到 B 口后，B 更新了本地 FDB，A 还保留旧出接口（A 自己的下联口），回程流量哈希到 A 就入 = 出丢弃，黑洞最长 12s，直到 A 收到 VM 的 GARP/ICMP 触发 MAC 漂移检测才收敛。
- DRCP 30s≠MAC 同步：DRCP 报文是 M-LAG 邻居保活 / 协商，不携带 FDB 表项。MAC 表项同步走 peer-link 控制通道，是另一套，别把两个时间混在一起。
- 跨组（AB→CD）丢包也符合常理：双核心是独立转发面，只有收到 VM 迁移后源报文的核心更新了 FDB，另一核心保留旧表项，ECMP 哈希命中旧表项就持续丢到收到源报文刷新为止。GARP 只刷新途经设备，刷不到另一台核心。
- 要让单挂口 MAC 更新后立即同步给 M-LAG 邻居：把 VM 所属 VLAN 配置成
m-lag extra-vlan。官方文档 “实时同步” 的前提就是这个 ——DR 聚合口默认实时同步，单挂口必须靠 extra-vlan 才触发实时推送。 - 你观察的丢包现象完全符合转发常理，是 VM 热迁移 + 单归接入的典型 MAC 漂移黑洞。
- 对症手段：场景 1 配
m-lag extra-vlan+ 开启mac-address move检测；场景 2 需在虚拟化侧迁移后多发 GARP 刷新两台核心，或改造 VM 双归，核心侧无法仅靠 M-LAG 根治。
- 2026-09-15回答
- 评论(0)
- 举报
-
(0)
暂无评论
1. 虚拟机在 AB 交换机组内迁移，回程流量哈希到交换机 A 导致丢包的原因
在 M-LAG 机制中，当虚拟机从节点 1 迁移到节点 2 时，虚拟机会通过新接口（连接交换机 B）发送免费 ARP（GARP）或 ICMP 报文来更新网关的 MAC 表。交换机 B 收到报文后，会立即更新本地 MAC 表，将虚拟机 MAC 的出接口更新为自身的下行物理口。
然而，M-LAG 不会自动同步从下行（DR 口）学习到 MAC 地址的刷新动作给对端（交换机 A）。此时交换机 A 的本地 MAC 表中，该虚拟机 MAC 的出接口依然指向其自身的旧物理口。当网关回程流量基于哈希算法被分发到交换机 A 时，交换机 A 会直接从旧的物理口转发该报文，而此时虚拟机已经不在该物理口下，导致报文进入“黑洞”被丢弃。只有当交换机 A 收到该虚拟机发来的新报文时，才会重新学习并更新 MAC 表，或者等待旧 MAC 表项老化。
2. 虚拟机跨 AB 和 CD 交换机组迁移，核心 B 丢包的原因
核心交换机 A 和 B 是两台独立的三层设备，它们之间的 MAC 表是独立学习的，不会自动同步。当虚拟机迁移到 CD 组并发送报文经过核心 A 时，核心 A 更新了 MAC 表；但如果外部测试 PC 的回程流量哈希到了核心 B，核心 B 的 MAC 表尚未更新，依然指向旧的 AB 组。核心 B 将流量发给 AB 组后，AB 组发现入接口和出接口相同（或找不到有效出接口），从而丢弃报文。这属于跨设备三层网关在 MAC 迁移时的正常收敛延迟。
3. M-LAG 单挂接口 MAC 更新后是否会立即同步？
M-LAG 的 Peer-link 确实用于同步 MAC 地址表项，但这里存在一个关键区分：M-LAG 主要同步的是“新增的 MAC 地址”或“单挂设备的 ARP/MAC”（通过 IPL 泛洪或 copy 机制）。对于已有 MAC 地址的出接口刷新（MAC 漂移/迁移），M-LAG 原生机制不会通过 Peer-link 实时同步刷新指令给对端。
您观察到的
display m-lag drcp statist inter br 中 30 秒的同步时间，是 DRCP 协议报文（DRCPDU）的发送周期（长超时模式下为 30 秒发送一次），它主要用于维护 Peer-link 状态和协商配置，并不是用来实时同步 MAC 迁移表项的。4. 有没有办法让 M-LAG 设备更新 MAC 后立即同步给邻居？
这是 M-LAG 的设计逻辑决定的：下行接入侧属于独立的学习域，设备各自独立学习下行 MAC，跨设备不自动同步上行动态 MAC 的刷新。
解决/缓解方案：
- 依赖 VMware 免费 ARP：您提到 VM 侧已勾选“通告交换机”功能，这是正确的。VM 迁移后会发送免费 ARP，这能加速网关和直连交换机的 MAC 更新。
- 缩短 MAC 老化时间：在接入交换机上适当缩短 MAC 地址的老化时间（例如从默认的 300 秒缩短到 30-60 秒），可以加快黑洞窗口的收敛，但会增加交换机 CPU 负担，需权衡使用。
- 开启对话式 MAC 学习（如支持）：部分厂商（如 H3C）提供
mac-address drni forwarding-conversational-learning功能，可以在一定程度上缓解 MAC 迁移时的收敛问题，但不能做到绝对的零丢包。
5. 上述丢包情况是否符合转发常理？
在 M-LAG 双活网关或二层透传场景下，虚拟机迁移（MAC 漂移）必然存在一个收敛窗口期（通常为几秒到十几秒）。在这个窗口期内，由于两台 M-LAG 设备的本地 MAC 表不一致，加上网关或上游设备的流量哈希机制，部分回程流量必然会命中旧 MAC 表项导致丢包。这在业界被称为“MAC 迁移黑洞”，是 M-LAG 架构的固有特性，并非设备故障或 Bug。
暂无评论
设备：核心 S105X-G，接入 S6526XE，M-LAG，服务器单挂 ACCESS 口，迁移已开启通告交换机。
1、同组内迁移丢包（最长 12 秒黑洞）
- M-LAG 配对设备之间新 MAC 是实时同步，但旧 MAC 表项不会被同步报文直接删除。
- 虚拟机迁移后，B 交换机学到新 MAC 并同步给 A 交换机；但 A 交换机硬件里旧 MAC 条目还保留。硬件转发优先级：本设备本地学习 MAC > M-LAG 同步过来的 peer-link MAC。
- 回程流量哈希到 A 交换机，匹配旧端口转发，端口下已经没有业务，报文丢弃，形成黑洞，直到旧 MAC 老化删除（你观测 12s 就是当前 MAC 老化时长）。
- DRCP 周期报文（30s）只是邻居保活协商报文，和 MAC 表同步无关，不要把 DRCP 统计时间当成 MAC 同步周期。
2、跨 Leaf 组迁移，外部访问概率丢包
- 核心两台设备虽然是 M-LAG 配对，但外网流量做负载分担。
- 迁移后报文到达核心 A，更新 MAC 表；核心 B 上旧 MAC 条目还没老化。
- 外部流量哈希到核心 B 时，查表把流量转发到老接入组；老接入设备收到报文，入接口和出接口相同，直接丢弃。哈希到核心 A 的流量正常转发。这个现象符合二层转发逻辑。
3、单挂接口 MAC 更新是否实时同步
单挂接口新学习 MAC、MAC 移动事件，M-LAG 邻居之间事件触发实时推送，不是等待 30s 周期。30s DRCP 报文只用于保活，不负责 MAC 同步。
4、能否做到 MAC 更新立刻同步并清理旧表项
M-LAG 协议可以实时推送新 MAC，但不能远程清除另一台设备上已经存在的旧 MAC，属于硬件转发优先级机制限制。 优化方案：
- 开启
mac-address mac-roaming enableMAC 漫游，MAC 移动场景快速刷新表项 - 调低 MAC 老化时间（不要过小，防止正常表项误删）
- 版本支持则开启
m-lag single-home fast-update单归快速更新 - 虚拟化侧配置多条免费 ARP 连续发送，多次触发表项刷新
二层 MAC 迁移无法做到绝对零丢包，只能缩短丢包窗口。业务零丢包场景推荐分布式网关方案。
5、现象是否符合转发常理
✅ 符合。属于 M-LAG 单归接入 + 服务器迁移场景的典型现象，不是设备故障。
排查命令
display mac-address timer
display mac-address mac-roaming
display mac-address <虚拟机MAC>
display m-lag peer
display m-lag drcp statistics interface Bridge-Aggregation x
接入侧推荐配置
system-view
mac-address mac-roaming enable
mac-address timer aging 10
m-lag single-home fast-update暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论