m-lag standalone enable 问题

在H3C M-LAG场景中，当设备因peer-link和keepalive链路故障触发m-lag standalone enable独立运行模式后，‌链路修复后的恢复流程如下‌：

一、恢复触发条件

1. ‌链路恢复检测‌
   peer-link和keepalive链路重新连通后，M-LAG设备通过‌keepalive报文‌感知对端存活状态‌。
2. ‌M-LAG状态机切换‌
   设备从standalone模式切换为restore状态，进入恢复延迟期（由m-lag restore-delay 900控制）‌。

二、恢复流程关键步骤

1. ‌恢复延迟期等待‌
   设备等待‌900秒‌（restore-delay配置值），确保链路稳定性并避免因瞬时抖动导致反复切换‌。

   • 此阶段设备仍以独立模式转发流量，但开始同步MAC表、ARP表等关键信息‌。

2. ‌主备角色协商‌
   延迟期结束后，通过‌DFS Group优先级‌或‌设备MAC地址‌重新选举主备角色‌：

   • 优先级高的设备成为主设备（Master），另一台为备设备（Backup）‌。
   • 若优先级相同，MAC地址较小的设备成为主设备‌4。

3. ‌数据平面同步‌
   主设备通过peer-link向备设备同步以下信息：

   • ‌MAC地址表‌：确保双活设备转发路径一致‌。
   • ‌ARP表‌：避免IP地址解析错误‌。
   • ‌LACP状态‌：重新协商聚合口状态，恢复双活负载分担‌。

4. ‌业务流量回切‌
   同步完成后，M-LAG恢复双活模式，流量重新通过peer-link和成员端口负载分担‌。

三、配置与状态验证

1. ‌查看M-LAG状态‌
   display m-lag summary # 确认状态为"Active-Active"
2. ‌检查同步结果‌
   display m-lag consistency-check # 验证配置一致性‌:ml-citation{ref="1,3" data="citationList"}
3. ‌监控恢复日志‌
   display m-lag event-log # 观察"Peer-link recovered"和"Restore completed"事件‌:ml-citation{ref="1,2" data="citationList"}

四、恢复机制设计原则

五、异常处理建议

• ‌同步失败场景‌：
  若display m-lag consistency-check显示配置不一致，需手动修复差异配置后重启M-LAG进程‌。
• ‌流量黑洞风险‌：
  恢复期间建议启用m-lag traffic-redirect enable临时重定向流量至主设备‌