Chassis Cluster Overview
A chassis cluster provides high redundancy. Before you begin managing an SRX Series chassis cluster, you need to have a basic understanding of how the cluster is formed and how it works.
Chassis cluster functionality includes:
A 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.
To form a chassis cluster, a pair of the same model of supported SRX Series devices are combined to act as a single system that enforces the same overall security. Chassis cluster formation depends on the model. For SRX3400 and SRX3600 chassis clusters, the location and type of Services Processing Cards (SPCs), I/O cards (IOCs), and Network Processing Cards (NPCs) must match in the two devices. For SRX5600 and SRX5800 chassis clusters, the placement and type of SPCs must match in the two clusters.
An SRX Series chassis cluster is created by physically connecting two identical cluster-supported SRX Series devices using a pair of the same type of Ethernet connections. The connection is made for both a control link and a fabric (data) link between the two devices.
Hardware Requirements
This following hardware components are required to support chassis clusters:
SRX1400, SRX3400, SRX3600, SRX5600, or SRX5800 Services Gateways
SRX100, SRX200, or SRX600 Series branch devices
Software Requirements
This following software components are required to support chassis clusters:
Junos OS Release 9.5 or later
Junos OS Release 10.1R2 or later for SRX Series branch device virtual chassis management and in-band management
For more information about how to form clusters, see the Junos OS Security Configuration Guide.
Control Plane and Data Plane
When creating a chassis cluster, the control ports on the respective nodes are connected to form a control plane that synchronizes configuration and kernel state to facilitate the chassis clustering of interfaces and services. The data planes on the respective nodes are connected over the fabric ports to form a unified data plane.
The control plane software operates in active/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 a system or hardware failure. If the primary device fails, the secondary device takes over processing the 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 the cluster from the other node.
When a device joins a cluster, it becomes a node of that cluster. With the exception of unique node settings and management IP addresses, nodes in a cluster share the same configuration.
You can deploy up to 15 chassis clusters in a Layer 2 domain. Clusters and nodes are identified in the following ways:
A cluster is identified by a cluster ID (cluster-id) specified as a number from 1 through 15.
A cluster node is identified by a node ID (node) specified as a number from 0 to 1.
Chassis clustering of interfaces and services is provided through redundancy groups and primacy within groups. A redundancy group is an abstract construct that includes and manages a collection of objects. A redundancy group contains objects on both nodes. A redundancy group is primary on one node and backup on the other at any time. When a redundancy group is said to be primary on a node, its objects on that node are active. See the Junos OS Security Configuration Guide for detailed information about redundancy groups. Redundancy groups are the concept in Junos OS Services Redundancy Protocol (JSRP) clustering that is similar to a virtual security interface (VSI) in Juniper Networks ScreenOS® Software. Basically, each node has an interface in the redundancy group, where only one interface is active at a time. A redundancy group is a concept similar to a virtual security device (VSD) in ScreenOS Software. Redundancy group 0 is always for the control plane, while redundancy group 1+ is always for the data plane ports.