|
The default eBGP settings are quite conservative and were designed for best resource use when handling the full internet routing table. For private network environments, it is often desirable to tune the following BGP neighbor settings on both sides for faster failover.
- keep-alive-timer & holdtime-timer.
- connect-timer.
- advertisement-interval.
See below for an explanation of each one. See 'Recommended Settings' below for an example of BGP timer settings suitable for simple site-to-site VPNs.
Topology:
In this environment, Tunnel1 is the preferred link for sending data traffic between the two sites. Tunnel2 is intended as a backup.
For the test, there is an issue for HQ-Tunnel1 to Branch-Tunnel1 data traffic but other Internet traffic passes as normal between the sites. In this case, Dead Peer Detection will not bring down the tunnel and any failover mechanisms that rely on this will not activate.
keep-alive-timer and holdtime-timer:
With default settings, it takes a minimum of 120 seconds for routes over Tunnel1 to be removed. During this time the network will be disrupted even though there are valid routes available over Tunnel2.
Each neighbor sends a keep-alive after the keep-alive time (default 60 seconds) and expects to receive a reply.
If there is no response, Branch-EDGE keeps routes from the BGP neighbor 172.22.254.2 in the table for the holdtime-timer (default 180 seconds). Once this expires Branch-EDGE removes the neighbor and any routes received from it.
After at most 180 seconds, the BGP neighbor goes down on both sides. The non-functioning neighbor’s routes are removed and traffic fails over to Tunnel2 as intended.
To optimize this behavior, set a shorter keep-alive-timer and holdtime-timer.
connect-timer:
Sometime later, the tunnel issue has been resolved and Branch-EDGE can receive tunnel data traffic from HQ-EDGE. There is a delay of up to 60 seconds before the Tunnel1 neighborship is established.
By default the connect-timer is dynamic. Both sides are trying to bring the neighborship up, but the time between connection attempts is variable.
To optimize this behavior, set a short connect-timer.
advertisement-interval:
After the BGP neighborship is re-established, there is a delay of 30 seconds before Branch-EDGE receives any routes.
Initially, 172.22.254.2 will show as up but there will be no routes from it.
This is because HQ-EDGE is configured with the advertisement interval of 30 seconds. Branch-EDGE receives the route after 30 seconds.
To optimize this behavior, set a shorter advertisement-interval (0 is allowed).
Recommended Settings:
To apply all the above optimizations, update the BGP neighbor on both sides during a test window then hard reset the BGP neighborship.
config router bgp
config neighbor
edit <neighbor ip>
set advertisement-interval 1
set keep-alive-timer 2
set holdtime-timer 6
set connect-timer 1
next
end
end
The change is only applied by hard resetting the BGP neighbor using the router clear command. This will interrupt routing to that neighbor and it's recommended to do this during a test window.
execute router clear bgp ip <bgp neighbor ip>
After applying the recommended settings on both sides and restarting the neighborship, failover takes 5-7 seconds and failback takes approximately 2 seconds.
For configuration options enabling sub-second failovers, see FortiGate SD-WAN or BFD.
Related documents:
Facilitating the fastest BGP route failovers
How to Clear BGP sessions
Configure IPsec VPN with SD-WAN
FortiGate BFD implementation
Configuring DPD (dead peer detection) on IPsec VPN
|
