Hello @nusaka ,
There are several parameters that can affect failover time in your network structure, which seems to consist of at least one hub and two spokes. Here's a visualization of the nearest best practice approach:
1-Ensure IP connectivity of your private blocks over the internet, typically achieved using IPsec.
2- Each spoke location should have two internet connections, with IPsec established between the hub and spokes.
3- Establish IP connectivity between spokes and the hub.
4- Configure dynamic routing under your IPsec tunnel to handle private network announcements and network connectivity loss.
5-Configure SD-WAN with performance SLA targets to monitor IPsec tunnels for metrics like delay, jitter, and packet loss.
6-Enable session pick-up capability to ensure TCP sessions remain on the passive device.
This describes the best practice topology for handling routing and reachability between spokes and a hub, minimizing client impact during failover such as nearly zero downtime. It emphasizes the importance of network stability and setting up infrastruccture to be fully redundant from every perspective of network design.
PS: Avoid power-down tests for failover scenarios and instead consider methods like disabling the primary IPsec tunnel interface or forcing HA failover by using "execute ha failover set " commmand.
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.
Hi Nusaka
You may be able to reduce the fail-over delay this in SD-WAN's performance SLA section.
A fail-over may impact user connection depending on how critical internet connection is, but I hope your ISP is reliable and doesn't fail frequently, otherwise you may change it.
Rebooting FG and SD-WAN fail-over are not the same test and don't have the same purpose, so I don't think we can say one is better then the other.
