Hub-Spoke 双线路隧道抖动

2025/10/29大约 4 分钟

Hub-Spoke 双线路隧道抖动

网络拓扑

Spoke 与 Hub 均有 2 条线路接入 Internet。
Hub 的 ISP1 和 ISP2 线路上分别创建一个拨号类型的 IPSec 连接：
- Hub 上的两条拨号 IPSec 隧道一阶段配置中，开启add-route功能，根据 Spoke 的源保护网段自动添加去往 Spoke 的路由。
- 二阶段源目保护网段均为 0.0.0.0/0，默认配置下，route-overlap状态为use-new。
Spoke 的 ISP1 线路与 Hub1 的 ISP1 线路建立 IPSec 连接，Spoke 的 ISP2 线路与 Hub1 的 ISP1 线路建立 IPSec 连接。
- Spoke 上的两条 IPSec 隧道二阶段配置中，源保护网段均配置为明细的 192.168.101.0/24，目的保护网段配置为 0.0.0.0/0。
由于 Spoke 两条线路的上的 IPSec 二阶段配置的源保护网段一样（192.168.101.0/24），所以理论上 Hub 在实现add-route时，应该添加 2 条目标为 192.168.101.0/24 的路由，并等价负载到两条拨号隧道上创建的子隧道。这也是用户想要实现的需求。

问题现象

重要

在升级 FortiOS 7.0.13、7.2.6、7.4.1 及更新版本后，会出现此问题，这是正常情况，功能机制随版本发生了变化。

Spoke 上的 SD-WAN 健康检查检测 Hub 端的资源，出现丢包现象。

Spoke # diagnose sys sdwan health-check
Health Check(Spoke1):
Seq(4 VPN1): state(dead), packet-loss(95.000%) sla_map=0x0
Seq(5 VPN2): state(alive), packet-loss(11.000%) latency(9.479), jitter(4.353), bandwidth-up(19999998), bandwidth-dw(19999998), bandwidth-bi(39999996) sla_map=0x0

在 Hub 上查看 IPSec 一阶段（IKE）状态，多次执行查看命令，已创建时间一直处于很短的状态。

Hub # diagnose vpn ike gateway list | grep "name:\|created"
name: VPN2_0
//created: 1s ago//
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 2/2 established 2/2 time 0/0/0 ms
name: VPN1_0
//created: 1s ago//
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 1/1 established 1/1 time 10/10/10 ms

查看 Hub 上通过add-route功能添加的路由，只有一条隧道上添加了去往 Spoke 内网的路由。

Hub # get router info routing-table details 192.168.101.0

Routing table for VRF=0
Routing entry for 192.168.101.0/24
Known via "static", distance 15, metric 0, best
* via VPN1 tunnel 200.52.10.17, tun_id

问题原因

通过diagnose debug application ike -1查看 IPSec Debug 信息，可以看到 IPSec 不停地在两条隧道上添加和删除去往 Spoke 的路由。

Hub # diagnose debug application ike -1
Hub # diagnose debug enable

ike 0:VPN1_0:562:1753: peer proposal is: peer:0:192.168.101.0-192.168.101.255:0, me:0:0.0.0.0-255.255.255.255:0
ike 0:VPN1_0:562:Spoke1LAN:1753: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:1748: moving route 192.168.101.0/255.255.255.0 oif VPN2(32) metric 15 priority 1 to 0:VPN1:1753
ike 0:VPN2:1748: del route 192.168.101.0/255.255.255.0 tunnel 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1:1753: add route 192.168.101.0/255.255.255.0 gw 200.52.10.17 oif VPN1(31) metric 15 priority 1
ike 0:VPN2:563:1755: TSi_0 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:563:Spoke1-LAN_E:1755: TSi_0 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2_0:563:Spoke1-LAN_E:1755: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN1:1753: moving route 192.168.101.0/255.255.255.0 oif VPN1(31) metric 15 priority 1 to 0:VPN2:1755
ike 0:VPN1:1753: del route 192.168.101.0/255.255.255.0 tunnel 200.52.10.17 oif VPN1(31) metric 15 priority 1
ike 0:VPN2:1755: add route 192.168.101.0/255.255.255.0 gw 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1_0:564:1761: peer proposal is: peer:0:192.168.101.0-192.168.101.255:0, me:0:0.0.0.0-255.255.255.255:0
ike 0:VPN1_0:564:Spoke1LAN:1761: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:1755: moving route 192.168.101.0/255.255.255.0 oif VPN2(32) metric 15 priority 1 to 0:VPN1:1761
ike 0:VPN2:1755: del route 192.168.101.0/255.255.255.0 tunnel 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1:1761: add route 192.168.101.0/255.255.255.0 gw 200.52.10.17 oif VPN1(31) metric 15 priority 1

这是由于 Hub 端在执行add-route功能时，由于两条 Spoke 隧道使用的源保护网段一样，Hub 认为这两个保护网段冲突：
- 当 Hub 的 IPSec 二阶段中的route-overlap状态为use-new（默认配置）时：每个 Spoke 网段只能添加一条路由到路由表，后建立的 IPSec 隧道会导致前边已建立的 IPSec 隧道及其添加的相同路由被移除。这样就会出现两条隧道不停翻转（overlap）的情况。
- 当 Hub 的 IPSec 二阶段中的route-overlap状态为allow时：允许同时在两个隧道上添加去往 Spoke 内网的路由。

解决方法

在 Hub 的两条 IPSec 拨号连接的二阶段配置中，将route-overlap状态配置为allow。

config vpn ipsec phase2-interface
    edit "VPN1"
        set route-overlap allow
    next
    edit "VPN2"
        set route-overlap allow
    next
end

查看 Hub 上通过add-route功能添加的路由，两条隧道上都添加了去往 Spoke 内网的路由，并等价负载。

Hub # get router info routing-table details 192.168.101.0

Routing table for VRF=0
Routing entry for 192.168.101.0/24
Known via "static", distance 15, metric 0, best
* via VPN2 tunnel 115.38.6.12, tun_id
* via VPN1 tunnel 200.52.10.17, tun_id