1. 最可能的原因：“VPN切换”与“路由切换”的检测对象不一致

• 主墙测试时，电信断 → 移动通；电信恢复 → 电信通。说明主墙的回切逻辑正常。
• 备墙测试时，电信断 → 移动通；电信恢复 → 仍走移动。

核心区别在于：备墙在电信恢复后，是否依然认为“电信方向的GRE隧道是DOWN的”？

如果备墙上的GRE隧道状态没有恢复为UP（例如对端只允许主墙建立隧道，或备墙的隧道源地址/目的地址配置与主墙冲突），那么备墙的路由表里电信方向的路由永远不可达，自然就不会切回。

RBM+NQA+GRE‑VPN，故障恢复后不回切问题解析

现象：电信主链路故障，RBM+NQA 探测 GRE 隧道 IP，成功切移动备用 VPN；电信链路恢复，NQA 探测 GRE 隧道已经恢复可达，但业务路由、VPN 不切回电信主链路，持续跑移动。 重点：H3C RBM 双机热备【默认不开启流量回切】，故障恢复不会自动抢占回主设备H3C。

一、最核心根因（概率最高）

RBM 视图下没有配置delay‑time X，流量回切功能默认关闭H3C。

行为逻辑：

1. 电信链路故障，Track/NQA 状态 Negative，触发 RBM 主备倒换；备墙升主，流量切移动 VPN。
2. 电信链路恢复，NQA 探测 GRE 隧道恢复 Positive，Track 状态恢复正常。
3. 但是 RBM 没有开启回切，即便监控对象全部恢复正常，不会把角色抢占回原主墙，流量继续停留在备墙（移动出口）。

✅开启回切配置（两台防火墙都要配置）：

⚠️注意：故障发生之后再敲这条命令，对本次故障无效，仅对下一次故障生效；必须故障发生前预先配置H3C。

二、第二类根因：NQA/Track 状态没有真正回到 Positive

虽然物理链路恢复，但 GRE 隧道接口 / 对端隧道 IP 还没有通，Track 状态没有变为 Positive，RBM 认为故障依旧存在，不会触发回切。

排查命令（主 / 备墙都执行）

坑点：

1. NQA 探测源 IP 配置错误，探测包不是从 GRE 隧道源发出；虽然公网通，但 GRE 隧道内部不通，探测依然失败。
2. GRE/IPsec 隧道恢复需要时间，NQA 立刻探测，隧道还没 Up，Track 短暂保持 Negative。

优化：track 增加 positive 延迟，等待隧道协议收敛：

三、第三类根因：GRE VPN 表项 RBM 同步限制

RBM 对 VPN 同步限制：仅 IKEv1 策略模式 IPsec 支持表项备份；GRE 隧道本身配置同步，但隧道运行表项、会话不会实时备份H3C。

• 当备墙升主跑移动 GRE；电信链路恢复，原主墙 GRE 隧道虽然 up，但VPN 会话、静态 / 策略路由表项状态不同步。
• 即使 RBM 角色切回主墙，原主墙 GRE‑VPN 会话没有重建，路由选择依旧走移动。

优化建议：

1. 不要单纯只探测 GRE 隧道 IP；NQA 探测目标，优先探测对端内网业务 IP，而不是隧道接口 IP。隧道接口 Up≠业务真正通。
2. 策略路由联动 Track，配合 RBM，区分设备角色；不要完全依赖 RBM track 联动接管全部 VPN 切换。

四、第四类：RBM 双机稳态未就绪，回切条件不满足

即使 delay‑time 配置完成，设备系统未达到稳态，不会执行抢占回切。

查看业务板、引擎是否全部 steady 状态；如果业务板不稳定，RBM 不会执行回切动作H3C。

五、完整排错操作步骤（现场执行顺序）

1. 检查 RBM 是否开启回切

确认输出存在delay‑time N；没有就配置delay‑time 3（两台设备都配）。

2. 核查 Track/NQA 真实状态

如果 Track 状态依旧 Negative：问题出在 NQA 探测本身（GRE 隧道没真正通、源 IP、策略放通探测报文） 如果 Track 已经 Positive，但不回切：就是 RBM 回切开关没有打开，或者系统未稳态。

3. 查看 RBM 运行角色

看谁是 current‑master。链路恢复后，即便 track 全部正常，如果 current‑master 仍然是备墙，就是回切没有触发。

4. 验证隧道业务连通性：不要只 ping 隧道对端地址，ping对端业务内网 IP。

六、组网优化建议（规避该类坑）

1. NQA 探测对象优先选对端业务内网 IP，而不是 GRE 隧道接口 IP；隧道接口 UP 不代表业务可用。
2. track 配置delay positive 20~30，GRE 隧道协议协商需要时间，不要探测一成功立刻上报。
3. RBM 必须预先配置delay‑time，故障发生之后配置不生效。
4. 双出口 VPN 场景，建议：RBM 负责设备主备角色；策略路由 + track 负责出口 / VPN 选路，两套机制配合，不要把全部切换逻辑交给 RBM track。

临时手动切回测试：

手动强制主备倒换，验证切回之后业务是否正常。

备墙切换到移动 VPN 之后，路由表里已经存在了「移动 GRE 学到 / 静态配置的目标网段路由」；电信链路恢复时，虽然你的 NQA/Track 检测到电信 GRE 隧道 IP 通了、主静态路由本身生效，但这条主路由的优先级不高于已经存在的移动侧路由，路由表不会把移动路由踢掉，流量继续走移动。

主墙测试正常、备墙测试不正常，关键点是：主备防火墙是两台独立设备，备墙的路由来源、优先级、VRF、GRE 隧道状态逻辑和主墙不一样。

补充：H3C GRE 隧道本身是无状态！默认 Tunnel 接口只要本地有到达隧道目的公网 IP 的底层路由，Tunnel 接口就会一直 UP，哪怕隧道对端不通，Tunnel 接口协议不会自动 down。你靠 NQA ping 隧道内网 IP 来做 track，这个检测方式本身没问题，但路由优先级、路由来源才是这次回切失败的核心。

最常见 4 个原因（按概率排序，H3C 防火墙主备双出口 GRE 场景）

1）两条静态路由 preference 优先级配置错误（最高概率）

H3C 静态路由默认 preference=60，如果电信主路由、移动备路由都配 pre 60，当两条路由同时有效时，设备会做等价路由 ECMP，或者保留先注入路由表的那条（先入为主！）

• 故障过程：
  1. 电信断 → Track 把电信主静态路由删掉；移动浮动静态路由（pre 更大）注入路由表，流量切移动 GRE。
  2. 电信恢复 → Track 变成 Positive，电信主路由重新激活，加入路由表。
  3. 如果电信主 pre=60，移动 pre 也 = 60：路由表里面两条同时存在，设备不会自动替换旧路由，优先保留已经在表里面的移动那条，流量不切回。

✅ 正确配置逻辑：

• 电信主 GRE 静态路由：preference 60，绑定 track 1（检测电信 GRE 对端隧道 IP）
• 移动备用 GRE 静态路由：preference 100（更大数值，浮动路由，只有主路由失效才进路由表）

原理：只有主路由失效，高 pre 的备用路由才会浮上来；主路由恢复，pre 更小的主路由自动抢占，备用路由从路由表移除。

重点：备墙上面这两条路由的 pre 必须和主墙保持一致。很多人只在主墙配了浮动 pre，备墙忘记改。

2）移动 GRE 隧道通过动态路由（RIP/OSPF）学到对端网段，动态路由优先级比你的电信静态路由还低（pre 更小）

场景：GRE 隧道内跑 OSPF，移动隧道起来后，OSPF 学到对端网段，OSPF 外部路由 pre=15，比静态 60 优先级更高。

• 电信恢复后，电信静态路由 pre=60，OSPF 路由 pre 15 优先级更高，永远抢占，流量不会切回电信。

这个非常典型：你以为是静态路由切换，实际 GRE 隧道里跑了动态路由，动态路由一旦注入路由表，静态路由抢不赢。

排查命令：

看 Proto 字段：

• S = 静态；O=OSPF；R=RIP。只要不是 S，就是动态路由抢占。

3）NQA/Track 的 Positive 恢复延迟、或者 NQA 探测源地址错误（备墙独有的问题）

备墙测试场景，NQA ping 对端电信 GRE 隧道 IP：

• 探测报文源 IP 选错：用了移动出口的公网 IP 去 ping 电信 GRE 隧道 IP → 电信链路恢复后 NQA 一直探测失败，track 一直 Negative，主路由不启用。

NQA 的 ICMP-echo 一定要指定源地址为电信 GRE 隧道的源 IP / 电信公网接口 IP，不能不写 source。

同时检查 track 的 notification-delay positive（恢复延迟），如果设置很长，链路恢复后等很久才切。

4）备墙的两个 GRE 隧道底层公网路由（到 GRE 目的公网 IP）没有隔离，递归路由混乱

GRE 隧道依赖底层公网路由到达隧道 destination 公网 IP（电信 / 移动对端公网 IP）。

• 电信链路恢复后，到达电信 GRE 目的公网 IP 的底层路由，走了移动出口，GRE 封装报文从移动口出去，隧道虽然能 ping 通，但流量路径错乱。

现象：NQA ping 隧道 IP 通，track 状态 Positive，主静态路由生效，但 GRE 封装的外层报文还是走移动，业务流量不走电信。

排查：

看这条底层公网路由出接口是不是电信出口，不能走移动。

快速排查命令（备墙上面直接敲）

快速验证方法

1. 在备墙电信链路恢复后，执行 display ip routing-table 对端网段
   • 如果路由出接口还是 Tunnel1（移动 GRE），Proto 是 S，pre=60：就是优先级一样，等价路由 / 先入为主。解决：把移动静态路由 pre 改成 100。
   • 如果 Proto 是 O（OSPF）：动态路由抢占，需要修改 OSPF 外部路由优先级，或者 GRE 隧道不跑动态路由，只用静态 + track。
2. 确认 NQA 探测的 source 是电信接口，不是移动。

补充一个坑：GRE Keepalive

H3C Tunnel 接口默认没有 keepalive，底层公网通，Tunnel 接口就 UP，哪怕对端隧道 down。 你现在是 NQA ping 隧道内网 IP 来检测，这个方案可行。如果想让 Tunnel 接口本身感知隧道对端故障，可以配置：

5s 发送，重试 3 次失败，Tunnel 协议 down，绑定在 Tunnel 接口的静态路由直接失效。

推荐最简修复方案（适合你场景）

1. 主备两台防火墙，统一配置：
   • 电信主静态路由：pre 60 + track（NQA 检测电信隧道内网 IP，源指定电信公网口）
   • 移动备用静态路由：pre 100，不加 track，作为浮动静态路由。
2. GRE 隧道内部不要跑动态路由，全部用静态指向 Tunnel 接口；如果必须 OSPF，要修改 OSPF 外部路由优先级 > 60。
3. NQA 一定要写 source interface，保证探测报文从电信出口发出。
4. 检查到达 GRE 封装目的公网 IP 的底层路由，电信目的公网 IP 必须走电信出口，移动目的公网 IP 走移动出口，防止递归路由混乱。

你遇到的这个问题，核心原因在于RBM主备状态与路由/隧道状态出现了脱节。简单来说，电信链路恢复后，备墙虽然检测到了，但控制路由切换的“开关”（Track项）并未同步恢复，导致它认为电信方向依旧不可用，因此路由无法切回。

 核心原因：检测对象与状态不同步

• 检测对象错位：你在备墙上检测的是“对端GRE隧道IP”，这不同于直接检测“公网下一跳”。如果备墙的GRE隧道因配置冲突（如源地址与主墙相同）而未能恢复UP状态，那么负责切换路由的Track项就会持续为Negative，路由自然不会切回电信。

• RBM与路由控制脱节：RBM负责主备状态切换，而静态路由本身不会感知RBM状态。当电信恢复后，如果备墙上关联电信路径的Track项仍为Negative，那么指向移动的备用路由会因优先级更高而继续生效。

• 备墙角色与抢占延迟：在RBM主备模式下，默认流量回切功能可能未开启，或回切延迟（delay-time）设置过长，导致备墙在电信恢复后仍长时间保持业务主状态，不将流量回切。

 排查与解决步骤

1. 检查备墙的Track与NQA状态

在备墙上执行以下命令，确认关联电信路径的Track项状态：

重点关注Track项状态是 Positive（正常）还是 Negative（异常）。如果电信恢复后仍为Negative，说明NQA探测失败或Track未联动。

接着检查NQA测试结果：

确认对端GRE隧道IP是否可达。如果不可达，需排查备墙GRE隧道的源/目的地址、路由及对端配置。

2. 修正检测对象（推荐方案）

将NQA检测目标从“对端GRE隧道IP”改为检测电信公网的下一跳网关IP。这样只要电信线路本身恢复，Track项就能立即变为Positive，触发路由回切。

注意：如果无法修改检测对象，也可在备墙上配置EAA（Embedded Automation Architecture），通过脚本在NQA状态恢复后自动执行命令，间接实现路由回切。

3. 调整RBM回切策略

确保RBM的流量回切功能已开启，并设置合理的抢占延迟，避免链路抖动导致频繁切换：

同时，检查 delay-time 参数，它控制RBM切换后的延迟时间，建议设置为30秒至5分钟，给路由收敛留出足够时间。

4. 验证GRE隧道状态

在备墙上执行 display interface tunnel，确认电信方向的GRE隧道接口状态是否为 UP。如果为DOWN，说明隧道本身未建立成功，需要检查：

• 隧道源地址（通常为备墙的电信接口IP）是否正确。

• 隧道目的地址是否可达。

• 对端是否允许备墙建立隧道（部分场景下对端可能只允许主墙的隧道源地址）。