FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Not applicable
Article Id 191310

Article

Description This article describes how to use FortiOS v2.80 CLI commands to control how a FortiGate HA cluster synchronizes routing table updates between cluster units.
Products All FortiGate models numbered 60 and higher.
Details

In a functioning cluster, the primary unit must keep all subordinate unit routing tables up to date.

It is possible to use the following CLI commands to control the timing of routing table updates.

 

Command syntax.

 

# config system ha

  set route-hold <hold_integer>

  set route-ttl <ttl_integer>

  set route-wait <wait_integer>

end

 

route-hold <hold_integer>.

 

The time that the primary unit waits between sending routing table updates to subordinate units in a cluster.

The route hold range is 0 to 3600 seconds.

The default route hold time is 10 seconds.

 

To avoid flooding routing table updates to subordinate units, set route-hold to a relatively long time to prevent subsequent updates from occurring too quickly.

 

The route-hold time should be coordinated with the route-wait time. See the route-wait description for more information.

 

route-ttl <ttl_integer>.

 

The time to live for routes in a cluster unit routing table.

The time to live range is 0 to 3600 seconds. The default time to live is 0 seconds.

 

The time to live controls how long routes remain active in a cluster unit routing table after the cluster unit becomes a primary unit.

To maintain communication sessions after a cluster unit becomes a primary unit, routes remain active in the routing table for the route time to live while the new primary unit acquires new routes.

 

Normally, the route-ttl is 0 and the primary unit must acquire new routes before it can continue processing traffic.

 

Normally acquiring new routes occurs very quickly so only a minor delay is caused by acquiring new routes.

If the primary unit needs to acquire a very large number of routes, or if for other reasons, there is a delay in acquiring all routes, the primary unit may not be able to maintain all communication sessions.

 

It is possible to increase the route time to live if communication sessions are lost after a failover so that the primary unit can use routes that are already in the routing table, instead of waiting to acquire new routes.

 

>route-wait <wait_integer>.

 

The time the primary unit waits after receiving routing table update before sending the update to the subordinate units in the cluster.

 

For quick routing table updates to occur, set route-wait to a relatively short time so that the primary unit does not hold routing table changes for too long before updating the subordinate units.

 

The route-wait range is 0 to 3600 seconds. The default route-wait is 0 seconds.

Normally, because the route-wait time is 0 seconds the primary unit sends routing table updates to the subordinate units every time the primary unit routing table changes.

 

Once a routing table update is sent, the primary unit waits the route-hold time before sending the next update.

 

Usually routing table updates are periodic and sporadic. Subordinate units should receive these changes as soon as possible so route-wait is set to 0 seconds. route-hold can be set to a relatively long time because normally the next route update would not occur for a while.

 

In some cases, routing table updates can occur in bursts.

A large burst of routing table updates can occur if a router or a link on a network fails or changes.

 

When a burst of routing table updates occurs, there is a potential that the primary unit could flood the subordinate units with routing table updates.

Setting route-wait to a longer time reduces the frequency with which additional routing updates are sent, which prevents flooding of routing table updates from occurring.

 

Contributors