分裂之后怎么恢复
堆叠分裂（双主）发生后，恢复的目标不是简单重启：先要确认检测机制是否触发、哪一侧被抑制、业务当前由谁承载，再按预案决定保留哪一侧、如何把另一侧合入。恢复动作里最容易出问题的是顺序——先恢复链路、还是先合入成员、还是先对齐配置，顺序不同，二次震荡的概率差别很大。
基本信息
| 首要判断 | 检测是否触发、哪侧被抑制、业务由谁承载 |
|---|---|
| 信息入口 | 堆叠状态、日志、检测链路状态 |
| 恢复依据 | 两侧配置差异比对结果与业务承载情况 |
| 关键动作 | 重启或合入失败侧，使其重新加入 |
| 收尾核对 | 转发表、协议邻居、告警与业务指标 |
典型使用场景
- 堆叠线缆断开导致分裂：按预案快速恢复并复盘
- 检测失效未抑制：需要人工判断并抑制某一侧
- 恢复后业务异常：核对转发表与协议邻居是否收敛完成
- 演练复盘：把实际恢复过程与预案对比，修正流程
- 事件归档：把恢复记录整理为后续演练与培训材料
恢复前核对
恢复前核对
display stack # 两侧成员、角色与拓扑状态
display logbuffer | include STACK # 分裂发生的时间点与原因
display logbuffer | include MAD # 检测与抑制相关记录（按平台关键字）
display interface brief # 关键链路当前状态
display eth-trunk 1 verbose # 跨框聚合的成员分布
# 核心判断：谁在转发、谁被抑制、配置差异有哪些恢复步骤与核对点
| 步骤 | 动作 | 核对点 |
|---|---|---|
| ① 现场判断 | 确认检测状态与业务承载侧 | 是否已抑制，抑制是否生效 |
| ② 差异比对 | 对比两侧配置与版本 | 保留侧的配置是否为最新基线 |
| ③ 执行恢复 | 重启或合入失败侧 | 成员是否按预期身份加入 |
| ④ 收敛核对 | 查看表项、协议邻居与告警 | 转发是否完整、有无残留告警 |
| ⑤ 记录归档 | 形成事件记录与改进项 | 预案是否需要修订 |
恢复判据要写进预案：两侧配置差异已比对清楚、失败侧按主侧基线对齐或重启后重新加入、合并后逐项核对 MAC 表、ARP、协议邻居与告警状态。
恢复动作建议与人工确认结合：自动化脚本在配置差异未核清的情况下执行，可能把错误配置同步到另一侧，造成二次震荡。