Description

This article explains why session counts could vary between the nodes of an SRX cluster, and whether any action must be taken to resolve the difference.

Symptoms

Users may find a mismatch in the number of sessions between the nodes of an SRX cluster in the show security flow session summary output.

user@node0> show security flow session summary
node0:
--------------------------------------------------------------------------
Unicast-sessions: 1450 <<<<<<<<<<<<<
Multicast-sessions: 0
Failed-sessions: 0
Sessions-in-use: 1780
Valid sessions: 1450
Pending sessions: 0
Invalidated sessions: 330
Sessions in other states: 0
Maximum-sessions: 10485760

node1:
--------------------------------------------------------------------------
Unicast-sessions: 1699 <<<<<<<<<<<<<
Multicast-sessions: 0
Failed-sessions: 0
Sessions-in-use: 1846
Valid sessions: 1699
Pending sessions: 0
Invalidated sessions: 147
Sessions in other states: 0
Maximum-sessions: 10485760

Solution

Some possible reasons for the values to be different are as follows:

  • By design, when a session is closed on the primary node, the session-close sync message (run-time object or RTO) is not immediately sent to the secondary node, but rather, the primary node waits and batch processes several RTOs together over to the backup node. This slight delay would cause sessions to exist on the secondary node that have already been closed on the primary node.

  • When stand-alone/orphan (non-reth) interfaces are used, sessions from these interfaces are not synchronized between nodes. They exist only on the node where the interface exists (unless Z-mode is in use).

  • When there is packet loss on the fabric link, it could cause session-create or session-close RTOs to be lost, which would affect session synchronization between nodes.

  • Session-close message contains details of multiple sessions. Hence the packet size would be jumbo frames. When fabric links are connected through a switch, the jumbo frame feature on the corresponding switch ports must be enabled otherwise the large session-close messages would be dropped resulting in session accumulation on backup node.  When the issue is seen in case of vSRX, ensure that the HA vNIC on hypervisor and the underlay path supports jumbo frames.

 

As explained in the previous section, it is normal for these values to differ. However, if you have reason to suspect any fabric link issues, the following documentation might prove useful:

Modification History

Version 1