堆叠升级与滚动重启
堆叠升级按整组进行：上传新版本、指定启动文件，再按从成员、备设备、主设备的顺序逐台重启，业务在其余成员上继续转发。单成员重启期间它的端口链路会中断、跨框聚合的成员数减少，带宽需要按剩余成员重新估算。
基本信息
| 升级方式 | 上传版本、指定启动文件、逐台重启成员 |
|---|---|
| 重启顺序 | 从成员 → 备设备 → 主设备 |
| 业务影响 | 单成员重启期间其端口链路中断 |
| 关键核对 | 全组成员版本一致性与业务状态 |
典型使用场景
- 版本升级、补丁修复与安全加固
- 大版本切换前的兼容性验证与试点
- 升级过程中核对成员加入与版本同步情况
- 升级失败后按预案回退到旧版本
- 割接前确认窗口时长与业务影响范围
升级过程核对
升级过程核对
display version # 查看成员当前版本
display stack # 逐成员重启与重新加入过程
# 指定下次启动文件（命令形式随平台不同）
startup system-software xxx.cc
display startup # 核对下次启动版本
display stack # 升级后核对成员版本一致性升级要点
| 项目 | 说明 | 注意 |
|---|---|---|
| 升级顺序 | 从成员 → 备 → 主 | 主设备最后重启 |
| 业务影响 | 单成员端口中断 | 带宽按剩余成员估算 |
| 版本一致性 | 全组成员版本需一致 | 版本不符可能无法加入 |
| 备份 | 升级前备份配置与版本 | 保留回退路径 |
升级期间转发能力下降：单成员重启意味着它的端口链路中断、跨设备聚合成员减少，业务容量要按剩余成员重新核算。
主设备重启窗口最长，一般安排在窗口末段执行，并提前确认备设备能够独立承载全部业务。
版本不一致的成员可能无法加入堆叠，升级完成前避免新增或替换成员，以免混入不兼容的版本。