Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Chassis Cluster Overview

Chassis clustering provides network node redundancy by grouping a pair of the same kind of supported SRX Series devices or J Series devices into a cluster. The devices must be running the same version of the Junos operating system (Junos OS). The control ports on the respective nodes are connected to form a control plane that synchronizes the configuration and kernel state to facilitate the high availability of interfaces and services. Similarly, the data plane on the respective nodes is connected over the fabric ports to form a unified data plane. The fabric link allows for the management of cross-node flow processing and for the management of session redundancy.

The control plane software operates in active or backup mode. When configured as a chassis cluster, the two nodes back up each other, with one node acting as the primary device and the other as the secondary device, ensuring stateful failover of processes and services in the event of system or hardware failure. If the primary device fails, the secondary device takes over processing of traffic.

The data plane software operates in active/active mode. In a chassis cluster, session information is updated as traffic traverses either device, and this information is transmitted between the nodes over the fabric link to guarantee that established sessions are not dropped when a failover occurs. In active/active mode, it is possible for traffic to ingress the cluster on one node and egress from the other node.

Note: In Junos OS Release 10.4, SRX Series and J Series devices running IP version 6 (IPv6) can be deployed in active/active (failover) chassis cluster configurations in addition to the existing support of active/passive (failover) chassis cluster configurations. An interface can be configured with an IPv4 address, IPv6 address, or both. Address book entries can include any combination of IPv4 addresses, IPv6 addresses, and domain name system (DNS) names.

High-end SRX series devices have a chassis cluster control port that is used to connect two SRX Series devices to form a chassis cluster. To ensure secure login and to prevent attackers from gaining privileged access through this control port, an internal IPsec SA is installed. Besides using internal IPsec to secure RSH and RCP between the primary and backup Routing Engines, the internal IPsec SA is installed on all the Services Processing Units (SPUs). An attacker cannot access any of the RSH services without knowing the internal IPsec key.

The internal IPsec SA requires authorization for RSH on SPU and the Routing Engine. For telnet, authorization is only required for SPU since telnet for Routing Engine requires a password.

You set up the IPsec internal SA using the security internal-security-association CLI command. You can configure the security internal-security-association on a node and then enable it to activate secure login. The security internal-security-association CLI command does not need to be set up on each node. When you commit the configuration, both nodes are synchronized.

Note: The SA in this scenario is not the point-to-point security association, because it is used to communicate with any Routing Engine or SPU on the internal network. Only 3des-cbc encryption algorithm is supported.

When secure login is configured, the IPsec based rlogin (for starting a terminal session on a remote host) and rcmd (remote command) commands are enforced so an attacker cannot gain privileged access or observe traffic that contains administrator commands and outputs.

Chassis cluster functionality includes:

• Resilient system architecture, with a single active control plane for the entire cluster and multiple Packet Forwarding Engines. This architecture presents a single device view of the cluster.
• Synchronization of configuration and dynamic runtime states between nodes within a cluster.
• Monitoring of physical interfaces, and failover if the failure parameters cross a configured threshold.
• Support for Generic Routing Encapsulation (GRE) tunnels used to route encapsulated IPv4/IPv6 traffic by means of an internal interface, gr-0/0/0. This interface is created by Junos OS at system bootup and is used only for processing GRE tunnels. See Junos OS Interfaces Library for Security Devices.

At any given instant, a cluster can be in one of the following states: hold, primary, secondary-hold, secondary, ineligible, and disabled. A state transition can be triggered because of any event, such as interface monitoring, SPU monitoring, failures, and manual failovers.