Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] Active session timeout value is longer than backup session after Chassis Cluster failover

0

0

Article ID: KB31791 KB Last Updated: 27 Jun 2020Version: 2.0
Summary:

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 Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search