Chassis Cluster Overview

Chassis Cluster Architecture

The cluster nodes are interconnected through two links—the control link and the fabric link— and synchronize configuration data, kernel state, and Packet Forwarding Engine (PFE) session information to support high availability, stateful service failover, and load balancing.

No seperate license is required to enable chassis cluster functionality. However, certain Junos OS software features require a license to activate. For more information, see Understanding Chassis Cluster Licensing Requirements, Installing Licenses on the SRX Series Devices in a Chassis Cluster and Verifying Licenses on an SRX Series Device in a Chassis Cluster. For general details on license management, refer to Juniper Licesnsing Guide. For product-specific information, referSRX Series Services Gateways, or contact your Juniper account team or authorized Juniper Partner.

Benefits of Chassis Cluster

Chassis clustering provides the following advantages:

• Prevents single device failure that results in a loss of connectivity.

• Delivers high availability between devices when connecting branch and remote site links to larger corporate offices.

• Ensures uninterrupted service during device, interface, or link failures.

• Preserves stateful traffic sessions during failover events.

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.

Chassis Cluster Modes

A chassis cluster can be configured in an active/active or active/passive mode.

• Active/passive mode: In active/passive mode, transit traffic passes through the primary node while the backup node is used only in the event of a failure. When a failure occurs, the backup device becomes primary and takes over all forwarding tasks.

• Active/active mode: In active/active mode, has transit traffic passing through both nodes of the cluster all of the time.

How Chassis Clustering Works?

In a chassis cluster, the control ports on the respective nodes are interconnected to form a control plane that synchronizes configuration and kernel state, enabling high availability for interfaces and services.

Similarly, the data plane on each node is connected through the fabric ports to form a unified data plane.

The fabric link supports cross-node flow processing and session redundancy management.

Control plane software operates in either active or backup mode. In a chassis cluster configuration, the two nodes back up each other, with one node acting as the primary device and the other as the secondary.This architecture ensures stateful failover of processes and services during system or hardware failures.

The data plane software operates in active/active mode. Session information is continuously updated as traffic traverses either node, and is synchronized between nodes over the fabric link to ensure that established sessions are preserved during failover.

In active/active mode, traffic can ingress the cluster on one node and egress from the other. When a device joins a chassis cluster, it becomes a node within that cluster. Exceptfor node-specific settings and management IP addresses, all nodes share the same configuration.

At any given time, a cluster operates in one of the following states: hold, primary, secondary-hold, secondary, ineligible, or disabled. Transitions between these states can occur due to events such as interface monitoring, SPU monitoring, hardware or software failures, or manual failover actions.

IPv6 Support in Chassis Clusters

Firewalls running IP version 6 (IPv6) support active/active (failover) chassis cluster configurations, in addition to the existing support for active/passive (failover) chassis cluster deployments. An interface can be configured with an IPv4 address, IPv6 address, or both. Address book entries can contain any combination of IPv4 addresses, IPv6 addresses, and Domain Name System (DNS) names.

Chassis clustering supports Generic Routing Encapsulation (GRE) tunnels for routing encapsulated IPv4 and IPv6 traffic through the internal gr-0/0/0 interface. This interface is automatically created by Junos OS during system bootup and is exclusively used for GRE tunnel processing. See the Interfaces User Guide for Security Devices.

Chassis Cluster Use Case

Enterprise and service provider networks implement multiple redundancy and resiliency mechanisms at the customer edge layer. Because this layer serves as the primary entry or peering point to the Internet, its stability and availability are critical. Customer traffic—including transactional data , email, Voice over IP (VoIP), and site-to-site communications—often traversesthis single access point to the public network. In environments where a site-to-site VPN is the sole connectivity method between branch locations and the headquarters, the reliability of this link becomes even more crucial.

Traditionally, redundancy at this network layer has been achieved by deploying multiple devices with separate configurations, often with mixed results. In such designs, enterprises rely on routing and redundancy protocols to provide a highly available customer edge. However, these protocols can be slow to detect failures and typically do not support the level of synchronization required to properly handle stateful traffic. Because a significant portion of edge traffic—whether to and from the Internet or between customer sites—is stateful, a persistent challenge at this tier has been ensuring session state is preserved during failover and recovery events.

Another challenge in deploying redundant devices is the need to configure, manage, and maintain multiple physical systems with separate configurations. Keeping these configurations synchronizedcan be difficult, particularly as security requirements grow in scope and complexity, increasing the likelihood of configuration mismatches. In secure environments, such inconsistencies can lead to issues ranging from simple connectivity loss to more serious and costly security breaches. Any abnormal condition at the customer edge can negatively impact uptime, which in turn affects service availability and may compromise the security of customer data.

One effective solution to the challenges of redundant customer edge configuration is the adoption of a state-aware clustering architecture, in which two or more devices operate as a single device. In this model, devices share session state information across the cluster, enabling near-instantaneous failover and recoveryfor stateful traffic. A critical measure of success for such architectures is their ability to transition traffic during failover and reversion events while maintaining the state of active sessions.

Deploying the chassis cluster configuration as described in Example: Configure Full Mesh Chassis Cluster reduces system downtime.

In an effective clustering architecture, devices can be managed as a single device that shares a common control plane. This capability is essential because it significantly reduces operational expenses associated with managing multiple standalone devices. Instead of operating separate devices with different configurations and management interfaces, you can manage multiple devices performing the same function through a single management point.

Additionally, clustered devices can monitor active interfaces to determine service state. A robust cluster continuously monitors all revenue interfaces and initiates failover to backup interfaces when a failure is detected. This monitoring and failover process occurs at near-instantaneous intervals to minimize service disruption and reduce the impact of a service failure (dropped customer calls, and so on).