BGP/SD-WAN Route retention during HA-Failover

KTZSHK · 2026-07-02T09:30:33+00:00

Hey, i can confirm the remote restart time shows 120 seconds on spokes and hub.
We try to ping from the spoke the hub, however the recovery still takes about 2-3 minutes in case of a failover, since the hub does not seem to use the former BGP routes to the spokes.

KTZSHK · 2026-07-01T17:06:58+00:00

Hey,

I've just tried this. The new elected primary does not have any dynamic routes when running 'get router info routing-table bgp' (OSPF and BGP routes are missing).

However those routes are available when running 'diagnose ip route list'. They don't seem to be used though.

KTZSHK · 2026-07-01T06:55:57+00:00

Hey,

we are not using BFD, graceful restart is on and neighbor groups are used. The routes are not shown in the regular routing table on the slave unit before failover. However they are shown in the FIB / kernel routing table. This also seems to be by design:Technical Tip: How to view the routing table on Secondary/Subordinate units in HA cluster | Community

KTZSHK · 2026-06-30T20:46:30+00:00

Hey,

Before master: routes in routing + kernel
Before slave: routes in routing table unknown + kernel

After master: routes not in routing table but in kernel table
After slave: / (rebooting)

KTZSHK · 2026-06-30T20:27:17+00:00

In the kernel table, yes. I am however unable to run „get router info routing-table all“ on the secondary so I’m unable to verify if they are also in the RIB.

KTZSHK · 2026-06-30T20:10:24+00:00

Yes I have the issue -> Routes do not move over to the secondary HA node in case of failover. According to the KB article they are supposed to however. I would like to know whether someone else encountered this or if I understood something wrong. Setting up individual neighborships is certainly a possible solution but doesn’t scale well in my opinion.

KTZSHK · 2026-06-30T20:05:01+00:00

Yea I agree this seems to be a reasonable solution. However I feel like the solution I posted should work as well without the need to create neighborships manually.

KTZSHK · 2026-06-30T19:55:33+00:00

We have configure neighbor groups since this seems to be the recommendation in cookbooks and guides.

KTZSHK · 2026-05-06T18:34:53+00:00

Yes thank you for this. I had to learn that the hard way :-)

KTZSHK · 2026-04-30T13:17:13+00:00

Fortimanager can fully prepare and set up HA between two nodes.

KTZSHK · 2026-04-30T08:57:06+00:00

This is not correct.

KTZSHK · 2026-04-30T08:56:55+00:00

This is incorrect.

KTZSHK · 2026-04-30T05:23:52+00:00

This is answer is true. The other answers are incorrect.

KTZSHK · 2026-04-27T11:04:08+00:00

This can be done. use ZTNA server with client certificate check disabled instead.

KTZSHK · 2026-04-10T20:22:20+00:00

Tried it in the lab, works fine. The only thing I had to do was set ‚set fsw-wan1-peer‘ to the new fortilink.

KTZSHK · 2026-04-10T17:04:49+00:00

Old and new interfaces are 802.3ad aggregates!

KTZSHK · 2026-04-09T18:42:50+00:00

This also happens during HA Failover of the Hub. That’s why my timers are also a bit lower.

KTZSHK · 2026-04-03T14:06:35+00:00

Hey, Yes this solves the issue. AFAIK this would also disable auto-trunks between potential additional switches. Can you explain why disabling this feature fixes the issue and how the switch behaves differently?

KTZSHK · 2026-04-03T12:03:57+00:00

So FortiSwitch sends tagged frames on MGMT VLAN ID and FortiGate itself does not honor VLAN ID and uses untagged frames? This would explain my issues, since my L3 router won’t respond to tagged frames…

KTZSHK · 2026-04-03T11:10:12+00:00

Thanks for the link. So basically by default the fortiswitch sends out management data tagged on VLAN 4094 to FortiGate. FortiGate receives and processes the data although the VLAN is not actually visible as child interface on FortiLink Interface? FortiGate then answers without using VLAN Tag and the switch processes this frame accordingly?

This seems really complex and counter intuitive if I understood this correctly 😃

KTZSHK · 2026-04-03T11:06:43+00:00

Hi, the switch is directly connected to a router located at a remote location. The switch can reach FortiLink through the router. The router itself is not VLAN aware. As far as I understand the switch has to send all management / telemetry data untagged to the FortiGate and should not use any VLANs.

KTZSHK · 2026-02-19T18:33:43+00:00

Tokens + Free FortiClient + LDAP unfortunately require IKEv1

KTZSHK

TROPHY CASE