不能把“业务未断”直接等同于 MLAG 已通过故障验证。MLAG 的双活能力通常建立在两台设备的协同控制状态、peer link 的状态同步，以及下游接入拓扑都满足前提的基础上。现场验收应分别证明：单设备或单上联故障时业务可收敛；peer link 异常时设备不会形成不可控双主；孤儿端口的转发与隔离符合设计；故障恢复不会因 MAC 重新学习或链路先后顺序制造二次抖动。
先界定本次演练能证明什么
只拔一条上联，通常只能覆盖该上联失效后的链路选择、聚合成员变化和部分流量收敛。若 peer link 仍正常、两台 MLAG 成员仍可通信，此测试并未触及控制平面失联后的 split-brain 风险，也未验证两侧对同一 MAC 的学习是否一致，更不能说明故障恢复时先恢复上联、后恢复 peer link，或反向恢复时均无影响。验收记录应把“单上联故障通过”明确标为局部场景，而非 MLAG 全场景通过。
把设计前提写成可检查条件
演练前确认两台成员设备的软件版本、MLAG 配置、互联承载方式、下游 LAG 与 VLAN 允许范围均已按现场基线核对。peer link 必须是被设计用于成员间同步和必要转发的路径；其带宽、冗余与故障域是否足够，不能仅凭逻辑已 up 判断。还要列出所有孤儿端口，即只连接到其中一台成员的普通接入口或单归属上联，并确认它们在对端成员故障、peer link 中断和双主保护触发时预期保留、阻断还是依赖上游收敛。
NVIDIA 的Networking Documentation按产品与软件版本提供配置和运维文档入口。涉及具体命令、状态字段、保护行为与平台限制时，应以所部署版本对应文档及设备实际输出为准，不应把其他平台或旧版本的行为直接套用到现场。
演练前先采集可回退的基线
- 冻结变更窗口，明确业务观察人、网络操作人和回退决策人，并准备带外管理通道。
- 保存两台成员的运行配置、接口状态、MLAG 邻接或对等状态、LACP 状态、VLAN 转发表及关键 MAC 表快照。
- 从至少两个业务端点持续观察双向连通性，并记录应用会话、丢包、时延趋势和告警时间戳；探测流量不能替代真实业务观察。
- 标注每个测试端点经过的下游聚合、普通接入口和上游路径，避免只从单一接入类型得出结论。
若环境使用 NVIDIA UFM Enterprise，还应根据已部署版本的UFM Enterprise User Manual核对其可见的事件、拓扑和告警能力。UFM 的观测记录可辅助关联时间线，但不能替代交换设备本身的 MLAG 状态、接口计数器和 MAC 表核验。
单上联故障应怎样执行
先选择一条已确认承载测试业务的上联，在变更记录中写明拔除或管理性关闭的方式。执行后依次检查：受影响接口是否按预期 down；剩余聚合成员和上游邻居是否仍可转发；MLAG 对等状态是否保持正常；业务端点的双向流量是否恢复；关键 MAC 是否仍从合理端口学习。不要只看 ping 成功，还应检查是否出现单向通、间歇丢包、异常泛洪或会话重建。
恢复该上联后，等待链路、LACP 与控制状态稳定，再比对恢复前后的 MAC 表和接口错误计数。若 MAC 在两台成员间持续漂移，或恢复后流量短暂绕行 peer link，应停止扩大测试范围，先定位 VLAN、聚合一致性、物理误接或上游收敛问题。
peer link 故障必须单独验证
peer link 演练的目标不是追求“所有端口都继续转发”，而是确认设备按设计进入可预期的保护状态。执行前必须确认双主检测或相关保护机制的实际配置，并知道不同状态下孤儿端口和下游 LAG 的预期动作。断开 peer link 后，观察两端角色或主备状态、对等失联告警、端口状态变化、转发表变化及业务影响。若两端均继续以可转发状态运行而缺少独立的双主判定条件，应将其视为高风险设计，不宜用业务暂时可用作为通过依据。
这里的反例很常见：两台成员各自仍连接不同上游或不同二层域，peer link 断开后都可能接收同一终端 MAC 的流量。此时即使单上联拔除演练完全成功，也不能排除重复转发、MAC 抖动或黑洞。是否存在此风险取决于拓扑和产品实现，必须按现场链路图及官方版本文档复核。
孤儿端口要按业务归属验收
孤儿端口不是天然不可靠，但它不具备跨两台成员的链路聚合冗余。对每个孤儿端口，应记录其连接对象、是否承载关键业务、故障时允许的中断范围，以及依赖的网关和上游路径。在单成员故障、peer link 故障和恢复阶段分别观察其连通性。若设计要求该端口在某类故障中被保护性阻断，出现中断反而可能是正确结果；验收依据应是预先批准的行为矩阵，而不是一律要求不中断。
用状态与证据判定通过
| 验证项 | 应保留的证据 | 异常信号 |
|---|---|---|
| 成员协同 | 两端 MLAG 对等、角色或主备状态时间线 | 状态不一致、反复切换 |
| 转发收敛 | 业务双向观察、接口计数器、LACP 状态 | 单向流量、持续丢包、异常错误计数 |
| MAC 学习 | 故障前后关键 MAC 表快照 | MAC 在不合理端口间反复移动 |
| 孤儿端口 | 每个端口对应的预期与实测结果 | 超出设计范围的可达或不可达 |
| 恢复过程 | peer link、上联、成员状态的恢复顺序和时间戳 | 恢复后黑洞、泛洪或二次业务抖动 |
恢复顺序和回退不能临场决定
恢复时优先遵循已批准的拓扑和厂商操作要求，通常应避免在成员间同步尚未建立时同时放开可能引入重复路径的转发条件。每完成一步都重新确认 peer link、成员协同、上联聚合和关键 MAC 表，再进入下一步。若出现双主迹象、MAC 持续漂移、关键业务异常或状态无法解释，应立即停止后续演练，按变更前保存的配置与物理连接回退，必要时维持受影响端口的保护状态并通过带外管理收集日志。回退完成后仍需复测业务和控制状态，不能因链路亮起就宣布恢复。
WeChat
Profile