Description

This article explains why the active session timeout value is longer than the backup session after Chassis Cluster failover.

Symptoms

​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

Solution

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.

Modification History

2020-06-27:  Article reviewed for accuracy; no changes required.

Related Information