Skip to main content
HS08
HS08
Visitor III
April 5, 2025
Question

ADVPN Failover

  • April 5, 2025
  • 1 reply
  • 562 views

I have topology with this details

- Hub subnet 10.103.0.0/16

- Spoke1 subnet 10.100.0.0/16

- Spoke2 subnet 10.4.0.0/16 and 10.107.0.0/16

- Hub and Spoke have 2 internet connection.

- ADVPN and BGP was established also with the shortcut tunnel

- ADVPN1 subnet 10.10.111.1/28 (hub 10.10.111.1, spoke1 10.10.111.2 and spoke2 10.10.111.6)

- ADVPN2 subnet 10.10.112.1/28 (hub 10.10.112.1, spoke1 10.10.112.2 and spoke2 10.10.112.6)

- SDWAN SLA from spoke2 to spoke1 in good conditions (all is green)

- SDWAN SLA from spoke1 to spoke2 in good conditions (all is green)

- Traffic from spoke1 to spoke2 via tunnel 10.10.111.6 

- Traffic from spoke2 to spoke1 via tunnel 10.10.111.2

With this scenario i try to disable tunnel 10.10.111.6 in spoke2  and this make spoke1 can't reach spoke2 and vice versa. From spoke1 point of view, routing table to 10.4.0.0/16 already change to 10.10.112.6

rt-s1.png

but why routing table on spoke2 to reach spoke1 still use 10.10.111.2.

rt-s2.png

Actually tunnel interface 10.10.112.0/28 is already disabled in spoke2.

ft1.jpg

1 reply

atakannatak
atakannatak
Explorer
April 7, 2025

Hi @HS08,

 

One possible reason for the issue is that even though tunnel 10.10.111.6 is down, BGP may still consider the old route valid and keep it in the routing table, leading Spoke2 to prefer the shortcut tunnel via 10.10.111.2 because it hasn’t received or selected an updated best path. Another possibility is that the tunnel interface is still considered UP — disabling it at the IPsec level doesn’t always mark it as down from a routing perspective, and FortiGate might still treat the interface as operational unless the IPsec session is fully terminated, causing SD-WAN and BGP to continue using the tunnel. Additionally, the SD-WAN rule may not be properly triggering failover; even if the SLA status is green, the rule might not be configured to switch to the secondary tunnel, and since SD-WAN rules are directional, the return path from Spoke2 to Spoke1 must be explicitly set to support failover based on SLA conditions.

 

To troubleshoot the issue follow the below steps:

 

  • Check the Routing Table: Verify the next-hop IP and interface for Spoke1’s subnet on Spoke2. Check if it's still pointing to the shortcut tunnel (10.10.111.2) instead of the backup tunnel (10.10.112.2).

         get router info routing-table details 10.10.111.2

 

  • Check BGP Status and Advertised Paths: Look at the prefixes received from the hub or other spokes. Confirm if Spoke2 has learned an alternative route to Spoke1’s subnet via the backup tunnel.

         get router info bgp network 10.100.0.0/16
         get router info bgp neighbors 10.10.111.2 received-routes
         get router info bgp summary

 

  • Clear BGP Routes: If routes haven't updated automatically, force BGP to reprocess. This clears and re-advertises routing updates.

         https://community.fortinet.com/t5/FortiGate/Technical-Tip-BGP-soft-reset-to-refresh-BGP-routing-table/ta-p/190141

 

  • Verify VPN Tunnel Status: Check if the shortcut tunnel is still seen as UP.

         diagnose vpn tunnel list

         diagnose vpn ike gateway list name

 

If you can share the outputs you receive after completing the steps above, we’ll be able to analyze them in more detail.

 

BR.

 

If my answer provided a solution for you, please mark the reply as solved it so that others can get it easily while searching for similar scenarios.

 

CCIE #68781

Terms & ConditionsAccessibility statement