Description

This article explains why the flow session timeout on a backup node is usually higher than on the primary node.

Symptoms

When the session is synced to the backup node, the timeout value on the backup node will in most cases reflect a timeout value of 8 times the initial value on the primary node. For example:

root> show security flow session
node0 :
--------------------------------------------------------------------------
Session ID: 25, Policy name: allow/6, State: Active, Timeout:  1788 , Valid
In: 10.2.1.2/60187 --> 10.1.1.2/22; tcp , If: reth1.0,  Pkts : 28, Bytes: 3268
Out: 10.1.1.2/22 --> 10.2.1.2/60187; tcp , If: reth0.0,  Pkts : 37, Bytes: 5077
Total sessions: 1
node1 :
--------------------------------------------------------------------------
Session ID: 4, Policy name: allow/6, State: Backup, Timeout:  14394 , Valid
In: 10.2.1.2/60187 --> 10.1.1.2/22; tcp , If: reth1.0,  Pkts : 0, Bytes: 0
Out: 10.1.1.2/22 --> 10.2.1.2/60187; tcp , If: reth0.0,  Pkts : 0, Bytes: 0
Total sessions: 1

Solution

In order to keep the traffic flowing uninterrupted after a failover, the sessions must be synchronized between the nodes. The session timeout value is refreshed every time when the traffic matches the session. However, the traffic matches the session only on the primary node, and constantly synchronizing the timeout value between the nodes would be a significant waste of resources. To avoid this, each created session (excluding ICMP sessions) will be synchronized towards the secondary node with a higher timeout (8 times the initial timeout set on the primary node). This happens over the fabric link, using RTO (real-time objects). For example, for TCP traffic, the timeout by default will be set to 14400 seconds (instead of 1800 seconds). 

This high timeout will be constantly decreasing, because the traffic will not be matching the session on the backup node. When it reaches zero, the backup node will request the current status of the session from the primary node. If the session is still alive, the timeout value on the backup node will be refreshed again, to the same high value. Whenever the session is closed, it is also deleted from the backup node. 

This mechanism ensures that if failover happens at any moment due to a failure on the primary node, the new primary node will have the session in place. 

This behavior is by design, it should not cause any issue.