Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Chassis Cluster Overview

    High Availability Using Chassis Clusters

    Modern networks require high availability. In order to accommodate this requirement, Juniper Networks SRX Series Services Gateways can be configured to operate in cluster mode, where a pair of devices can be connected together and configured to operate like a single node, providing device, interface, and service level redundancy.

    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.

    How High Availability Is Achieved by Chassis Cluster

    • The network node redundancy is achieved 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).
    • SRX Series devices must be the same model, and all SPCs, network processing cards (NPCs), and input/output cards (IOCs) on high-end platforms must have the same slot placement and hardware revision.
    • 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.
    • 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.

    Chassis Cluster Active/Active and Active/Passive Modes

    A chassis cluster in active/active mode has transit traffic passing through both nodes of the cluster all of the time. Whereas a chassis cluster in active/passive mode only has transit traffic passing through the primary node while the backup node waits in hot standby.

    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.

    The control plane software operates in active or backup mode.

    Chassis Cluster Functionality

    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 the Interfaces Feature Guide 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.

    IPv6 Clustering Support

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

    IPsec and Chassis Cluster

    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.

    Modified: 2017-01-16