Technical Tip: All configurable BGP timers on the FortiGate explained

Core Timers:

The following timers are considered core BGP timers required for establishing basic neighborships/peering.

set keepalive-timer

• Sets the frequency (0 - 65535 seconds, default = 60) for which the FortiGate sends BGP keepalive messages to established peers.

• keepalive-timer is the global setting used for BGP (config router bgp). This setting can be overridden on a per-peer basis (config neighbor/config neighbor-group) using the keep-alive-timer CLI option (note the extra hyphen in 'keep-alive').

set holdtime-timer

• Sets the maximum amount of time (3 - 65535 seconds, default = 180) that BGP will wait before marking a peer as dead.
  When the FortiGate receives a keepalive from the peer, the holdtime is reset back to this configured value. If no keepalives are received during this period, the FortiGate assumes the peer is no longer active and will bring down the BGP neighborship.
• holdtime-timer is the global setting used for BGP (config router bgp). This setting can be overridden on a per-peer basis (config neighbor/config neighbor-group) using the holdtime-timer CLI option (with the same name).

Note regarding keepalive/holdtime on FortiOS:

• Administrators can set the keepalive-timer to be greater than one-third of the holdtime-timer in the config, but the actual keepalive that FortiOS will use will be capped to a maximum of one-third of the holdtime (FortiOS enforces a suggestion from RFC 4271). On the other hand, using a keepalive timer that is shorter than one-third of the holdtime timer is allowed. For example:
  • If keepalive-timer = 20 and holdtime-timer = 30, then FortiOS will use an actual keepalive of 10 seconds and a hold time of 30 seconds.
  • If keepalive-timer = 5 and holdtime-timer = 30, then FortiOS will use an actual keepalive of 5 seconds and a hold time of 30 seconds.
• BGP keepalive/hold times are negotiated between peers such that the lowest advertised keepalive/hold time values are chosen.
• Additionally, changing the BGP keepalive-timer and holdtime-timer will not affect existing BGP neighborships until they are cleared and re-established (soft clearing is not sufficient in this case):

set advertisement-interval

• Sets the minimum interval (0 - 600 seconds, default = 30) that BGP waits to send routing updates.
• Routing updates affected by advertisement-interval include: initial route advertisement after the BGP adjacency state moves to ESTABLISHED, adding or withdrawing routes, and advertising routes after a soft reset.
• The advertisement-interval value is not required to match between peers. Each BGP peer waits to send its own route advertisements according to the locally configured advertisement-interval.
• FortiOS does not automatically adjust this timer based on iBGP vs. eBGP peerings, so it may be a good idea to consider setting a shorter interval for iBGP connections (as suggested in Section 10 of RFC 4271).

set connect-timer

• Sets the maximum amount of time (1 - 65535 seconds, default = 120) for the ConnectRetryTimer as described in BGP-4 RFC 4271. The actual timer used for a given connection attempt may be as low as half the configured connect-timer. 
• When the ConnectRetryTimer expires, FortiGate will initiate a new TCP connection attempt to the BGP peer.
• With default settings, the maximum amount of time between TCP SYN packets sent to an unresponsive neighbor is 152 seconds (32-second timeout for last TCP SYN + ConnectRetryTimer equal to the configured connect-timer).
• This setting is configured on a per-peer basis only and does not have an equivalent global setting.
• Note that the default value of this setting (and a few others) may display as 4294967295. See this KB article for an explanation of this behavior: Technical Tip: 'keep-alive-timer', 'holdtime-timer', 'connect-timer' and 'Weight' show a Default value of 4294967295 in the BGP neighbour configuration.

set scan-time

• Sets the background interval (5 - 60 seconds, default = 60, set 0 to disable) in which the FortiGate scans all BGP routes to check next-hop reachability (i.e., if a next-hop is no longer available, then do not use the route).
• Caution: disabling scan-time (set 0 to disable) causes the FortiGate to skip the next-hop check and could cause unexpected results. The FortiGate continues to advertise routes with next-hop unreachable to other BGP peers. These routes are installed in the FortiGate's local RIB as inactive routes and are considered invalid.

Route Dampening Timers:

The following timers are relevant to the BGP Route Dampening feature, which is discussed in further depth here:

Technical Tip: BGP Route Dampening in FortiGate Firewall

RFC 2439: BGP Route Flap Damping (Section 4.2)

'set dampening enable' must be set first for these timers to appear in the CLI, and these settings are global-only for BGP (no per-peer override).

set dampening-max-suppress-time

• Sets the maximum amount of time (1 - 255 minutes, default = 60) in which a route can be suppressed, regardless of how stable the route is.
• Default is notably four-times that of dampening-reachability-half-life.

set dampening-reachability-half-life

• Sets the half-life time for penalties (1 - 45 minutes, default = 15), where the penalty of the route is reduced by half if the route is considered to be reachable (suppressed or not).

set dampening-unreachability-half-life

• Sets the half-life time for penalties (1 - 45 minutes, default = 15), where the penalty of the route is reduced by half if the route is considered to be unreachable.

Graceful Restart Timers:

The following timers are relevant to the BGP Graceful restart feature, which is discussed in further depth here:

Technical Tip: Understanding Graceful restart and non-stop forwarding for BGP in FortiGate HA

Technical Tip: Configuring FortiGate HA and BGP graceful-restart to avoid traffic interruption during an HA failover

RFC 4724: Graceful Restart Mechanism for BGP

set graceful-restart-time

• Sets the length of time (1 - 3600 seconds, default = 120) that the FortiGate will wait while a BGP peer restarts. This timer is ended once the FortiGate receives a BGP OPEN message from the peer after it has restarted.
• graceful-restart-time is the global setting used for BGP (config router bgp). This setting can be overridden on a per-peer basis (config neighbor / config neighbor-group) using the restart-time CLI option.

set graceful-stalepath-time

• Sets the length of time (1 - 3600 seconds, default = 360) that the FortiGate will retain stale paths that had been previously received from a restarting BGP peer.
• This timer starts once the FortiGate detects that the remote peer has restarted (e.g., receiving a BGP Open with Graceful Restart Capability 'Restart State' bit set) and allows the FortiGate to retain existing stale routes long enough for BGP to re-establish and re-converge with the restarting peer.
• graceful-stalepath-time is the global setting used for BGP (config router bgp). This setting can be overridden on a per-peer basis (config neighbor/config neighbor-group) using the retain-stale-time CLI option.

set graceful-update-delay

• Sets the maximum amount of time (1 - 3600 seconds, default 120) that the FortiGate will wait to receive an End-of-RIB from all GR-capable remote peers after it performs a restart (an End-of-RIB marker is denoted by a BGP UPDATE message containing no Network Layer Reachability Information (NLRI) or withdrawals and is mandatory for Graceful Restart to indicate the completion of a BGP routing update).
• Unlike the previous two timers, this timer applies when the FortiGate is the one restarting BGP (as opposed to the remote peer restarting). In RFC 4724 Section 4.1, this timer is equivalent to the 'Selection_Deferral_Timer'.
• When the FortiGate restarts with Graceful Restart enabled, it must retain the existing stale routes it received from BGP peers (if possible) while it receives new route advertisements from these peers. However, it must not perform route-selection for these newly-received prefixes until one of the following conditions are met:
  
  1. It receives the End-of-RIB marker from all of its peers (except for those that do not support Graceful Restart, as well as those that have the 'Restart State' bit set), OR
  2. This timer has elapsed.
• Once the above conditions are met, the FortiGate will perform route selection (selecting and installing received routes), followed by advertising routes to its peers and concluding by sending its own End-of-RIB message out to signal the completion of the routing advertisement.
• Note: under the config router bgp, there is an option called graceful-end-on-timer (disabled by default) which directly integrates with the above timer.
  • When enabled, this option forces a restarting FortiGate to wait for the full graceful-update-delay timer to elapse before performing route-selection (even if all peers have sent End-of-RIB markers to the FortiGate). BGP peers will need to set longer stale path timers to compensate, as the FortiGate will not send route advertisements or its End-of-RIB marker to the peers until the timer elapses.
  • Enabling this setting is very useful in cases where the FortiGate needs to wait for the convergence of other routing protocols (such as OSPF) to occur so that their routes are redistributed into BGP and shared successfully with remote peers (AKA, BGP is waiting on other protocols to converge first, otherwise it will not be able to share a full routing table to the FortiGate's remote peers).
  • If this setting is disabled, then the FortiGate will perform route-selection as soon as all remote peers have sent End-of-RIB messages. The FortiGate will then send its own End-of-RIB messages to the BGP peers, which triggers them to delete their stale routes and replace them with whatever newly-received routes have been sent by the FortiGate.

Extra Tip:

Even minor adjustments to BGP timers can affect route convergence. Keep an eye on the neighboring states after changes using the following:

get router info bgp neighbors

get router info bgp summary

Related documents:

Troubleshooting BGP

Technical Tip: Configuring FortiGate HA and BGP graceful-restart to avoid traffic interruption during an HA failover

Technical Tip: Understanding Graceful restart and non-stop forwarding for BGP in FortiGate HA