Description

This document provides an overview of security flow session state following a Multi-Node High Availability (MNHA) failover event. 

Symptoms

Devices running MNHA can have 2 types of flow states, Active and warm. Active device will install the Active sessions and Backup node will install Warm session. When the failover happens from one node to another New back up nodes flow session will change from warm to active. However we can see a situation where the Active node has warm sessions as shown below.

 

root@SRX1> show chassis high-availability services-redundancy-group 1  
Oct 18 21:32:10
SRG failure event codes:
 BF BFD monitoring
 IP IP monitoring
 IF Interface monitoring
  CP Control Plane monitoring

Services Redundancy Group: 1
   Deployment Type: ROUTING
   Status: ACTIVE
   Activeness Priority: 50
   Preemption: DISABLED
   Process Packet In Backup State: YES
   Control Plane State: READY
   System Integrity Check: N/A
   Failure Events: NONE
Peer Information:
    Peer Id: 1
    Status : BACKUP
    Health Status: HEALTHY
    Failover Readiness: READY


root@SRX1> show security flow session protocol 61           
Oct 18 21:32:30
Flow Sessions on FPC0 PIC0:
Total sessions: 0


Flow Sessions on FPC0 PIC1:

Session ID: 1099512720969, Policy name: allow_vpn_in/15, HA State: Warm, Timeout: 14314, Session State: Valid
In: 19.156.16.200/1 --> 19.248.64.210/1;61, Conn Tag: 0x0, If: ae1.200, Pkts: 0, Bytes: 0, CP Session ID: 1680
 Out: 19.248.64.210/1 --> 19.156.16.200/1;61, Conn Tag: 0x0, If: st0.161, Pkts: 113270, Bytes: 13345712, CP Session ID: 1680



root@SRX2> show chassis high-availability services-redundancy-group 1  
SRG failure event codes:
 BF BFD monitoring
 IP IP monitoring
 IF Interface monitoring
 CP Control Plane monitoring

Services Redundancy Group: 1
   Deployment Type: ROUTING
    Status: BACKUP
   Activeness Priority: 100
   Preemption: DISABLED
   Process Packet In Backup State: YES
   Control Plane State: READY
   System Integrity Check: COMPLETE
    Failure Events: NONE

Peer Information:
    Peer Id: 2
    Status : ACTIVE
    Health Status: HEALTHY
     Failover Readiness: N/A


root@SRX2> show security flow session protocol 61
Flow Sessions on FPC0 PIC0:
Total sessions: 0


Flow Sessions on FPC0 PIC1:


Session ID: 1099515049072, Policy name: allow_vpn_in/15, HA State: Active, Timeout: 1800, Session State: Valid
In: 19.156.16.200/1 --> 19.248.64.210/1;61, Conn Tag: 0x0, If: ae1.200, Pkts: 113284, Bytes: 133448552, CP Session ID: 1685
 Out: 19.248.64.210/1 --> 19.156.16.200/1;61, Conn Tag: 0x0, If: st0.161, Pkts: 0, Bytes: 0, CP Session ID: 1685
Total sessions: 1

Solution

Dynamic routing protocols like BGP and OSPF are essential components of MNHA configurations and must be set up on both nodes. To ensure traffic is consistently directed to the active node, it advertises routes with appropriate BGP metrics, establishing itself as the preferred path. In the event of a failover, the backup node advertises the same routes but with adjusted metrics. This adjustment prompts upstream and downstream devices to install these routes as secondary options, redirecting traffic toward the new active node.

 

If upstream or downstream devices fail to update based on this route adjustment or if the backup node fails to advertise routes with modified metrics, traffic may continue to flow toward the backup node. This would result in the installation of active flow sessions on the backup node. However, these packets will be dropped, as illustrated below if it has to go through a tunnel:

 

root@SRX2> show security packet-drop records   
Packet-drop records on FPC0 PIC0:


Packet-drop records on FPC0 PIC1:
12:00:12.413062:FPC0PIC1: LSYS-ID-00 19.156.16.200/1-->19.248.64.210/1;61,ipid-0,st0.161,Dropped by IPSEC:Encrypt failed with inactive SA
12:00:12.404800:FPC0PIC1: LSYS-ID-00 19.156.16.200/1-->19.248.64.210/1;61,ipid-0,st0.161,Dropped by IPSEC:Encrypt failed with inactive SA
12:00:12.393792:FPC0PIC1: LSYS-ID-00 19.156.16.200/1-->19.248.64.210/1;61,ipid-0,st0.161,Dropped by IPSEC:Encrypt failed with inactive SA


However, if the customer has configured the following command under chassis high-availability, then packets will not be dropped and will instead be forwarded to the intended destination:

set chassis high-availability services-redundancy-group 1 process-packet-on-backup

With this configuration, when examining session values, you may observe that the session on the active node only shows packet counts in the OUT direction (response packets), while the session on the backup node displays packet counts in the IN direction (incoming packets). This behavior confirms that packets are being processed on the backup node and forwarded correctly, even though the active node maintains the session for response traffic.

 

Session on Active node

 

Session ID: 1099512720969, Policy name: allow_vpn_in/15, HA State: Warm, Timeout: 14314, Session State: Valid
In: 19.156.16.200/1 --> 19.248.64.210/1;61, Conn Tag: 0x0, If: ae1.200, Pkts: 0, Bytes: 0, CP Session ID: 1680
 Out: 19.248.64.210/1 --> 19.156.16.200/1;61, Conn Tag: 0x0, If: st0.161, Pkts: 113270, Bytes: 13345712, CP Session ID: 1680


Session on Backup node

 

Session ID: 1099515049072, Policy name: allow_vpn_in/15, HA State: Active, Timeout: 1800, Session State: Valid
 In: 19.156.16.200/1 --> 19.248.64.210/1;61, Conn Tag: 0x0, If: ae1.200, Pkts: 113284, Bytes: 133448552, CP Session ID: 1685
 Out: 19.248.64.210/1 --> 19.156.16.200/1;61, Conn Tag: 0x0, If: st0.161, Pkts: 0, Bytes: 0, CP Session ID: 1685


Since the routes were not updated correctly, the initial packet arrived at the backup node, which subsequently installed the active session.

 

To verify if there are any warm security flow sessions on the active node, you can run the command "show security flow session session-state warm" on the active node. If any warm sessions are identified, cross-check these sessions on the backup node to confirm their state.

 

The issue occurred because the subnet "19.248.64.0/24" was omitted from the prefix list used in BGP to control the route advertisements on the Active node. Adding this subnet to the prefix list on the Active node, as with other subnets, updated the path preferences on neighbouring devices as they should be.

Modification History

2024-11-08 : Article Created