防火墙RBM+VRRP组网下软件版本升级

先升级 Standby 备机，两台版本不一致中间态，RBM 建立、会话同步是否正常

结论：版本不一致中间态不建议长期运行；RBM 控制通道可以 Connected 连通，但是会话热备、配置同步存在风险，不保证完全正常H3C。

1. 控制通道：版本差异不大的情况下 RBM 控制通道可以 UP（display remote‑backup group status 看到 Connected）。
2. 会话表项热备（hot‑backup）：版本不一致时会话报文结构体、字段长度可能发生变化，会话同步不可靠，会出现会话丢同步；一旦此时发生意外主备切换，大量现有业务会话直接断流，无法平滑续接。
3. 配置同步：配置自动同步有可能校验失败，报配置摘要不一致日志，部分模块配置同步异常H3C。

⚠️重要约束：RBM 官方要求两台设备运行版本必须完全一致，版本不一致只允许短暂过渡，不允许作为稳态长时间运行。 正确操作：备机升级完成，确认业务板全部稳态、版本正常；立刻执行switchover request倒换，原主变备；然后升级原主设备；必须两台全部升级到新版本之后才算升级完成。 中间态风险点：禁止在版本不一致阶段做人为 / 意外主备切换。

问题 2：switchover request在哪台执行；切换后业务异常如何回退

1. 规范用法：优先在【当前业务主设备（Active）】执行switchover request，触发把业务切到对端 Standby 设备H3C。

虽然命令支持在备设备敲，但是不推荐；在备机执行容易造成状态预判混乱，生产尽量不在 Standby 上执行 switchover request。

2. 场景举例：

• 初始状态：FW‑A (Active)，FW‑B (Standby)
• 在 FW‑A 执行switchover request → FW‑B 变为新 Active，FW‑A 变为 Standby。
• 如果切换完成后业务异常，要做回退：需要在【新的业务主设备 FW‑B】RBM 视图下再次执行switchover request，业务切回 FW‑A。

回退逻辑：哪台当前是 Active 业务主，就在哪台执行 switchover request，业务切到对端，不是在刚刚退成备的机器敲命令。

补充该组网额外现象：RBM+VRRP + 对接 M‑LAG Leaf，switchover 执行瞬间会出现短暂 VRRP 虚拟 IP 冲突，属于手册标注的正常现象，一般 1‑3 秒恢复，提前告知业务方H3C。

问题 3：手册 “系统不允许 1 分钟内重复执行此功能”，是整个 RBM 系统还是单台设备

是针对整个 RBM 双机系统（RBM 组级别），不是单台设备。

只要 RBM 双机中任意一台执行过switchover request触发倒换，整个 RBM 组开始计时 1 分钟冷却；1 分钟之内，无论在哪一台设备再次敲 switchover request，命令直接拒绝执行，提示不允许重复执行该功能。 不是每台设备独立计时，是 RBM 组全局冷却计时器。 业务回退遇到 1 分钟冷却：只能等待冷却计时器超时之后再执行二次倒换，不要强制反复敲。

✅该现场完整安全升级操作步骤（RBM+VRRP 对接 M‑LAG）

1. 备份两台设备配置、导出技术支持信息。
2. 将新版本镜像上传至当前 Standby 备机，重启升级；升级完成后display version确认版本，display system stable state确认所有业务板稳态。
3. 确认 RBM 状态 Connected；⚠️此时版本不一致，严禁任何意外 / 手动主备切换。
4. 在当前 Active 主设备RBM 视图执行switchover request，业务切换至刚刚升级完的设备；确认 VRRP 状态、业务访问正常，确认 Leaf 侧 M‑LAG、ARP 学习正常。
5. 原来的主设备现在变为 Standby，上传镜像执行升级重启。
6. 两台全部升级完成、版本完全一致；观察 RBM 配置同步、会话热备状态正常。
7. 可选：业务窗口空闲时，再次执行 switchover request，把业务切回原有主设备位置。