This article explains why the active session timeout value is longer than the backup session after Chassis Cluster failover.
In a Chassis cluster Active/Passive environment, the sessions on the backup node are created with a timeout value of 8 times of the 'defined service-timeout' on the primary node.
If the Chassis cluster failover occurs, the new primary node will keep the session service timeout as earlier, until the new packet coming in refreshes the session timeout to be the defined service-timeout.
{primary:node0}
root@SRX01> show security flow session source-prefix 10.1.1.1 | no-more
node0:
--------------------------------------------------------------------------
Session ID: 8471, Policy name: 1003/7, State: Active, Timeout: 1768, Valid
In: 10.1.1.1/62647 --> 192.168.1.1/21;tcp, If: reth0.0, Pkts: 8, Bytes: 375
Out: 192.168.1.1/21 --> 100.100.100.100/40977;tcp, If: reth2.0, Pkts: 6, Bytes: 393
Total sessions: 1
node1:
--------------------------------------------------------------------------
Session ID: 68, Policy name: 1003/7, State: Backup, Timeout: 14368, Valid <--Backup session
In: 10.1.1.1/62647 --> 192.168.1.1/21;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Out: 192.168.1.1/21 --> 100.100.100.100/40977;tcp, If: reth2.0, Pkts: 0, Bytes: 0
Total sessions: 1
{primary:node0}
root@SRX01> request chassis cluster failover redundancy-group 0 node 1
node1:
--------------------------------------------------------------------------
Initiated manual failover for redundancy group 0
{primary:node0}
root@SRX01> request chassis cluster failover redundancy-group 1 node 1
node1:
--------------------------------------------------------------------------
Initiated manual failover for redundancy group 1
{secondary-hold:node0}
root@SRX01> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 2
node0 100 secondary-hold no yes None
node1 255 primary no yes None
Redundancy group: 1 , Failover count: 2
node0 100 secondary no yes None
node1 255 primary no yes None
{secondary-hold:node0}
root@SRX01> show security flow session source-prefix 10.1.1.1 | no-more
node0:
--------------------------------------------------------------------------
Session ID: 8471, Policy name: 1003/7, State: Backup, Timeout: 1724, Valid
In: 10.1.1.1/62647 --> 192.168.1.1/21;tcp, If: reth0.0, Pkts: 8, Bytes: 375
Out: 192.168.1.1/21 --> 100.100.100.100/40977;tcp, If: reth2.0, Pkts: 6, Bytes: 393
Total sessions: 1
node1:
--------------------------------------------------------------------------
Session ID: 68, Policy name: 1003/7, State: Active, Timeout: 14324, Valid <-- Backup Session became Active session.
In: 10.1.1.1/62647 --> 192.168.1.1/21;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Out: 192.168.1.1/21 --> 100.100.100.100/40977;tcp, If: reth2.0, Pkts: 0, Bytes: 0
Total sessions: 1
This is normal behavior for Junos session timeout adjustment after a failover. The new primary node will keep the session service timeout as earlier, until the new packet coming in refreshes the session timeout to be the defined service-timeout, or the session will be closed after timeout.
2020-06-27: Article reviewed for accuracy; no changes required.