2. VRRP active/standby组

VRRP active组和VRRP standby组：用于将RBM与VRRP进行关联，实现RBM对多个VRRP备份组状态进行统一管理的目的。

VRRP active/standby组分别有两种状态：Master状态和Backup状态。VRRP成员设备在VRRP备份组中的状态与所属VRRP active/standby组的状态保持一致。例如，VRRP active备份组的状态是Master，则该组中所有设备在VRRP备份组中的状态均为Master。

VRRP active/standby组的初始状态与RBM的工作模式有关，具体如下：

·     主备模式下：主管理设备上VRRP active组和VRRP standby组的初始状态均为Master；从管理设备上VRRP active组和VRRP standby组的初始状态均为Backup。

·     双主模式下：VRRP active/standby组的状态与主从管理设备角色无关，VRRP active组的初始状态为Master；VRRP standby组的初始状态为Backup。

3. RBM环境中Master设备的选举机制

将RBM与VRRP关联成功后，VRRP备份组中Master/Backup状态的变化机制如下：

(1)     正常情况下，Device A（假设其是主管理设备）上VRRP active组的状态是Master，所以Device A在VRRP备份组1和VRRP备份组2中的状态是Master设备。Device B（假设其是从管理设备）上VRRP standby组的状态是Backup，所以Device B在VRRP备份组1和VRRP备份组2中的状态是Backup设备。

(2)     当Device A的下行接口Interface A2故障后，RBM会收到接口故障事件。然后RBM发送VRRP active/standby组状态信息变更报文给Device B，通知Device B将其VRRP standby组的状态变更为Master。

(3)     Device B收到VRRP active/standby组状态信息变更报文后，会将自身VRRP standby组的状态变更为Master，同时将Device B在VRRP备份组1和VRRP备份组2中的状态变为Master设备。变更完成后给Device A发送应答报文。

(4)     Device A收到Device B的VRRP standby组状态变更成功应答报文后，将自己VRRP active组的状态变更为Backup，同时将Device A在VRRP备份组1和VRRP备份组2中的状态变更为Backup。

当Device A的下行接口Interface A2故障恢复后，流量会进行回切，VRRP备份组中Master/Backup状态的变化与接口故障时的变化过程类似，不再重复介绍。

看看这里

防火墙 RBM+VRRP：单个 VRRP 进入 Initialize，全部 VRRP 发生整机切换

现象截图解读：

• 第一台（原主）：RBM 通道established，协作模式All VRRP groups；VRID3 进入Initialize，其余 VRRP 为 Backup；整机全部 VRRP 变成 Backup。
• 对端备机：全部 VRRP 变为 Master，发生整机全部 VRRP 切换，并不是只有故障 VRID3 切换，其余正常 VRRP 也一起切过去了H3C。

根因：RBM 协作模式 All VRRP groups

这个模式的设计逻辑：把所有 VRRP 备份组绑定成一个整体，只要任意一个 VRRP‑active 组状态异常（Initialize/Down），RBM 就判定本机整机 VRRP 能力失效，触发整机所有 VRRP 全部切换到对端设备，保证上下行网关统一，避免部分 VRRP 主、部分 VRRP 备的脑裂场景H3C。

Initialize 含义：该 VRRP 组初始化失效，常见触发条件：接口 down、接口删除、接口 IP 被删、VRRP 配置异常、接口协议 down，VRRP 组进入 Initialize 状态，不再参与 VRRP 报文收发。 在All VRRP groups模式下：只要任意一个 active VRRP 组进入 Initialize，RBM 直接触发整机 VRRP 角色下沉为 Backup，所有 VRRP 全部切到备机。

第一步：先定位 VRID3 进入 Initialize 的真实原因

VRRP 进入 Initialize 常见诱因：

1. GE1/0/20 接口物理 down / 协议 down；
2. 接口 IP 地址被删除，VRRP 组没有有效主 IP；
3. 接口 shutdown；
4. 接口频繁震荡，导致 VRRP 反复初始化；
5. 版本 bug，VRRP 实例异常进入 Initialize。

注意：VRRP Initialize 不等于接口一定物理 down，也可能是接口协议层震荡。

两种 RBM 协作模式对比（关键选型）

表格

命令查看协作模式：

配置修改协作模式：

⚠️重要风险：切换为per‑vrrp‑group后，会出现部分 VRRP 主在 A、部分 VRRP 主在 B 的 “分裂状态”，如果业务存在上下行 VRRP（比如上行 VRID2，下行 VRID3），一旦下行 VRID3 故障切到备机，上行 VRID2 还在原主机，流量来回不通，业务直接中断。

所以：如果 VRRP 分别部署在上下行接口，不建议改成 per‑vrrp‑group。

故障处理方案

方案 1【推荐，保留 all‑vrrp‑groups 模式，根治根源】

不修改 RBM 协作模式，保持整机统一切换逻辑，解决 VRID3 接口 / VRRP 为什么会进入 Initialize 的底层问题。

1. 排查 GE1/0/20 接口：光模块、光纤、对端交换机端口、接口 CRC 错误、端口 up/down 震荡；
2. 确认接口 IP 地址稳定存在，不要删除接口主 IP；
3. 如果接口本身业务允许，配置接口监控 / 上行链路检测；
4. 检查防火墙版本，确认是否存在 VRRP 异常进入 Initialize 的版本缺陷，升级到官方稳定版本。

优势：维持 RBM 设计初衷，保证所有 VRRP 主备角色完全统一，不会出现上下行分裂。

方案 2【权衡取舍：修改为 per‑vrrp‑group】

仅当所有 VRRP 都在同一侧（全部是业务侧，不存在分离的上行 / 下行 VRRP），才建议修改。 效果：VRID3 故障仅 VRID3 切换，VRID1、VRID2 继续保留在原主设备，不会整机全部切换。 ⚠️风险警告：如果存在上行 VRRP、下行 VRRP 分别在不同接口，会造成上下行网关分属两台防火墙，业务直接不通，属于典型组网风险，需要评估业务。

补充排错关键点

1. RBM 控制通道是 established，RBM 心跳本身没问题，切换触发源是VRRP‑active 组状态事件，不是 RBM 通道断开。
2. 区分active和standbyVRRP 组：只有标记vrrp vrid X active的组才会触发 RBM 联动；standby 组状态异常不会触发 RBM 切换。
3. 查看日志：display logbuffer确认是VRRP group change to Initialize事件触发 RBM 整机 VRRP 状态切换。
4. 故障复现验证：复现时，优先抓 GE1/0/20 接口的状态变化，确认是接口先震荡，再触发 VRRP Initialize，再触发 RBM 全部 VRRP 下沉 Backup。

总结

1. 现象是预期行为，all‑vrrp‑groups模式就是任意一个 active VRRP 异常，全部 VRRP 一起切换，目的是规避上下行网关分裂；
2. 故障根源不是 RBM 机制，而是VRID3 所在接口 / VRRP 实例为什么进入 Initialize，优先定位接口层故障；
3. 不要轻易修改per‑vrrp‑group，如果组网有分开的上行、下行 VRRP，会引入更大业务风险。