Understanding the Chassis Cluster Data Plane
The data plane software, which operates in active/active mode, manages flow processing and session state redundancy and processes transit traffic. All packets belonging to a particular session are processed on the same node to ensure that the same security treatment is applied to them. The system identifies the node on which a session is active and forwards its packets to that node for processing. (After a packet is processed, the Packet Forwarding Engine transmits the packet to the node on which its egress interface exists if that node is not the local one.)
To provide for session (or flow) redundancy, the data plane software synchronizes its state by sending special payload packets called runtime objects (RTOs) from one node to the other across the fabric data link. By transmitting information about a session between the nodes, RTOs ensure the consistency and stability of sessions if a failover were to occur, and thus they enable the system to continue to process traffic belonging to existing sessions. To ensure that session information is always synchronized between the two nodes, the data plane software gives RTOs transmission priority over transit traffic.
Before You Begin |
|---|
- Understanding Session RTOs
- Understanding Data Forwarding
- Understanding Fabric Data Link Failure and Recovery
Understanding Session RTOs
The data plane software creates RTOs for UDP and TCP sessions and tracks state changes. It also synchronizes traffic for IPv4 pass-through protocols such as Generic Routing Encapsulation (GRE) and IPsec.
RTOs for synchronizing a session include:
- Session creation RTOs on the first packet
- Session deletion and ageout RTOs
- Change-related RTOs, which include:
- TCP state changes
- Timeout synchronization request and response messages
- RTOs for creating and deleting temporary openings in the firewall (pinholes) and child session pinholes
Understanding Data Forwarding
For JUNOS Software, flow processing occurs on a single node on which the session for that flow was established and is active. This approach ensures that the same security measures are applied to all packets belonging to a session.
A chassis cluster can receive traffic on an interface on one node and send it out an interface on the other node. (In active/active mode, the ingress interface for traffic might exist on one node and its egress interface on the other.)
This traversal is required in the following situations:
- When packets are processed on one node, but need to be forwarded out an egress interface on the other node
- When packets arrive on an interface on one node, but must
be processed on the other node
If the ingress and egress interfaces for a packet are on one node, but the packet must be processed on the other node because its session was established there, it must traverse the data link twice. This can be the case for some complex media sessions, such as voice-over-IP (VoIP) sessions.
Understanding Fabric Data Link Failure and Recovery
 | Note: Intrusion Detection and Prevention (IDP) services do not support failover. For this reason, IDP services will not be applied for sessions that were present prior to the failover. IDP services will be applied for new sessions created on the new primary node. |
The fabric data link is vital to the chassis cluster. If the link is unavailable, traffic forwarding and RTO synchronization are affected, which can result in loss of traffic and unpredictable system behavior.
To eliminate this possibility, JUNOS Software detects fabric faults and disables one node of the cluster. It determines that a fabric fault has occurred if a fabric probe is not received but the fabric interface is active.
To recover from this state, you must reboot the disabled node. When you reboot it, the node synchronizes its state and RTOs with the primary node.
| Note: If you make any changes to the configuration while the secondary node is disabled, execute the commit command to synchronize the configuration after you reboot the node. If you did not make configuration changes, the configuration file remains synchronized with that of the primary node. |
Related Topics
- JUNOS Software Feature Support Reference for SRX Series and J Series Devices
- Understanding Chassis Cluster Dual Fabric Links
- Connecting Dual Fabric Links for Devices in a Chassis Cluster
- Example: Configuring the Chassis Cluster Fabric (CLI)
- Verifying Chassis Cluster Data Plane Interfaces
- Verifying Chassis Cluster Data Plane Statistics
- Clearing Chassis Cluster Data Plane Statistics
- Understanding Chassis Cluster Formation