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 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 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.

• VRRP is not supported.
• Unified ISSU is not supported.
• The 3G dialer interface is not supported.
• Queuing on the ae interface is not supported.
• Group VPN is not supported.
• Starting with Junos OS Release 12.1X45-D10 and later, sampling features such as flow monitoring, packet capture, and port mirroring are supported on reth interfaces.
  • On all SRX Series devices in a chassis cluster, flow monitoring for version 5 and version 8 is supported. However, flow monitoring for version 9 is not supported.
  • If you use packet capture on reth interfaces, two files are created, one for ingress packets and the other for egress packets based on the reth interface name. These files can be merged outside of the device using tools such as Wireshark or Mergecap.
  • If you use port mirroring on reth interfaces, the reth interface cannot be configured as the output interface. You must use a physical interface as the output interface. If you configure the reth interface as an output interface using the set forwarding-options port-mirroring family inet output command, the following error message is displayed.

    Port-mirroring configuration error.
    Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

• The Chassis Cluster MIB is not supported.
• Any packet-based services such as MPLS and CLNS are not supported.
• On the lsq-0/0/0 interface, Link services MLPPP, MLFR, and CRTP are not supported.
• On the lt-0/0/0 interface, CoS for RPM is not supported.

Note: On SRX Series device failover, access points on the Layer 2 switch reboot and all wireless clients lose connectivity for 4 to 6 minutes. On SRX100 and SRX110 devices, switching is not supported in chassis cluster mode. The factory default configuration for SRX100 devices automatically enables Layer 2 Ethernet switching. Layer 2 Ethernet switching is not supported in chassis cluster mode for SRX100 devices. If you use the factory default configuration, you must delete Ethernet switching before you enable chassis clustering. On all high-end SRX Series devices, screen statistics data can be gathered on the primary device only. On all high-end SRX Series devices, an APN or an IMSI filter must be limited to 600 for each GTP profile. The number of filters is directly proportional to the number of IMSI prefix entries. For example, if one APN is configured with two IMSI prefix entries, then the number of filters is two. On all SRX Series devices, the packet-based forwarding for MPLS and ISO protocol families is not supported.