检查下链路情况

防火墙RBM状态频繁切换，通常是因为心跳链路或业务链路不稳定，触发了HA的选举机制。接口频繁Up/Down是导致切换的直接原因，可以参考以下步骤来系统地排查和解决。

 第一步：查看切换记录与日志，定位“真凶”

首先，需要明确每次切换的直接原因。

1. 查看RBM切换历史记录
   执行命令 display remote-backup-group switchover history。重点关注“Cause”（原因）列，如果显示为 Interface status changed，则说明故障确由接口状态变化触发。

2. 检查系统日志
   执行 display logbuffer 命令，重点搜索“%RBM/4/REAL_SWITCHOVER”（真实切换记录）、“interface”、“flaps”、“down”等关键字，以定位具体是哪个物理接口或聚合口在频繁震荡。

 第二步：检查物理链路与心跳线

接口频繁Up/Down，物理层面的问题最常见。

• 检查物理连接：检查所有参与RBM的接口（心跳口、业务口）的网线或光纤是否松动、损坏或接触不良。

• 检查光模块与对端设备：确认光模块工作正常，对端（如交换机）的端口状态是否同样不稳定。

• 检查端口错误计数：执行 display interface 命令，查看接口下是否有大量的CRC、碰撞等错误计数，这些是物理信号不佳的征兆。

 第三步：排查RBM与Track联动逻辑

如果物理链路正常，问题可能出在RBM的选举逻辑或Track配置上。

• 理解RBM的选举机制：RBM切换遵循一套优先级规则。

  1. 首先比较UP的业务接口数量：接口UP数量多的设备优先成为主设备。

  2. 若数量相同，再比较设备健康值（Health Value），健康值小的优先。

• 排查Track配置：很多切换由 track 接口状态变化触发。

  • 检查被 track 的接口，是否因STP收敛、生成树变化等被短暂阻塞。

  • 考虑将 track 的检测方式从单纯的 physical（物理状态）改为更可靠的 reachability（IP可达性），以避免物理层UP但数据层不通的误判。

• 检查设备健康值：执行 display system health 命令。若发现因历史故障（如板卡更换）导致健康值异常，可使用 reset-health-value 命令清除。

 第四步：检查并调整RBM定时器

不合理的定时器配置也可能导致震荡。

• 检查Keepalive参数：确保心跳链路的 keepalive interval（间隔）和 keepalive count（次数）设置合理。如果设置过小，网络轻微抖动就可能导致误判。

• 检查并调整回切延迟：这是最关键的参数之一。

  • 查看当前配置：在RBM视图下执行 display this 查看 delay-time 的值。

  • 若回切过快，可适当增大该值（单位为分钟），让主设备在接口恢复后等待一段时间再回切，避免频繁震荡。

  • 配置命令（在remote-backup-group视图下）：

    text

    delay-time <1-60> # 例如：delay-time 5

 第五步：检查软件与版本

如果以上都无效，考虑软件层面的问题。

• 检查RBM版本兼容性：确认当前防火墙软件版本是官方推荐的、稳定支持RBM的版本。

• 考虑升级：如果版本过旧或存在已知Bug，建议联系技术支持评估是否需要升级到最新稳定版

H3C 防火墙 RBM 双机频繁主备切换，Cause：Keepalive link disconnected /established

日志现象： Standby to Active，Keepalive link disconnected 保活链路断开→本设备升主； 紧接着Active to Standby，Keepalive link established保活链路恢复→切回备；周期性反复震荡。 根因：RBM 的 keepalive 保活链路不稳定，报文时通时断，不是业务链路故障，是 RBM 心跳链路抖动。

RBM 保活链路说明

RBM 双机的 keepalive 链路，有两种：

1. 物理 RBM 互联接口（RBM 直连线）；
2. 虚拟 keepalive（通过业务三层网络做心跳，不推荐）。 日志Keepalive link disconnected代表RBM 心跳报文收不到，设备判定 peer 故障，本机升主；当心跳报文恢复收到，又回切备机。

现象特征：两台防火墙来回抢主，业务会反复断流，日志成对交替出现 disconnected /established。

排查步骤，按优先级执行

1、先排查 RBM 物理互联接口层（硬件层面，最高概率）

1. 查看 RBM 接口物理状态，是否存在接口频繁 up/down、错包、CRC、溢出。

• 现象：接口有大量 CRC、input error，网线、光模块、光纤故障。
• 处理：更换网线 / 光模块；强制双工速率，不要 auto 协商。

注意：RBM 互联接口建议强制速率双工，不要自动协商，很多抖动来自协商异常。

2、确认 RBM 接口是否被其他业务占用，是否放通 VLAN

RBM 互联接口，推荐配置为RBM 专用接口，不要配置业务 IP，不要加入业务域。

重点看：

• RBM 的 keepalive 接口是否绑定正确物理接口；
• 如果是 VLAN 子接口做 RBM 心跳，确认中间交换机没有抖动、没有 STP 震荡、没有端口漂移。

###3、RBM 保活时间参数调优（报文层面） 默认 RBM keepalive 周期短，轻微丢包就触发切换。

调大检测阈值，避免轻微丢包误切换，interval 1000，retry‑times 5，避免网络瞬时抖动触发切换。 ⚠️不要调得过大，故障会导致切换变慢。

###4、排除 CPU 高负载，RBM 报文处理不过来 防火墙 CPU 占用过高，无法及时处理 RBM keepalive 报文，会报链路断开。

CPU 长时间高于 85%，会丢弃 RBM 心跳报文，造成虚假的 keepalive link disconnected。

###5、如果使用三层虚拟 keepalive 心跳（不推荐）

没有直连线，走业务网络传递 RBM 心跳报文。

1. 中间网络丢包、ACL、会话老化、QoS 限流，会直接造成心跳报文丢失；
2. 优先改成物理直连 RBM 接口，这是官方推荐部署方式。
3. 抓包验证：两台设备抓 keepalive 报文（UDP 8888），看报文是否丢包。

###6、版本 BUG 排查 部分老版本 F1000‑AK、F5000 系列版本存在 RBM 处理异常 bug，会出现虚假 keepalive 断开，查看版本说明书，确认是否存在 RBM 相关已知问题，必要时升级到稳定版本。

验证命令

高频踩坑总结

1. ❌RBM 互联接口网线 / 光模块故障，接口层偶发丢包，接口不 down，但是报文丢包，最常见；
2. ❌RBM 接口自动协商异常，建议强制速率双工；
3. ❌CPU 过高，防火墙来不及处理 RBM 心跳报文，误判 peer 离线；
4. ❌使用三层虚拟 keepalive 心跳，中间网络不稳定；优先物理直连 RBM 接口；
5. ❌keepalive 参数默认值，网络轻微抖动直接触发双机抢主；
6. ❌RBM 接口上配置业务、域间策略，干扰 RBM 私有报文。

临时应急：先调大 keepalive 间隔和重试次数，避免业务频繁切换；然后定位根因，不要长期依赖调大定时器掩盖硬件问题。