Chassis Cluster Overview

Benefits of Chassis Cluster

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

• Provides high availability between devices when connecting branch and remote site links to larger corporate offices. By leveraging the chassis cluster feature, enterprises can ensure connectivity in the event of device or link failure.

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?

The control ports on the respective nodes are connected to form a control plane that synchronizes 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.

When creating a chassis cluster, 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. 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.

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

SRX Series Firewalls 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.

Chassis cluster supports 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 User Guide for Security Devices.

Use case for SRX Chassis Clusters

Enterprise and service provider networks employ various redundancy and resiliency methods at the customer edge network tier. As this tier represents the entrance or peering point to the Internet, its stability and uptime are of great importance. Customer transactional information, email, Voice over IP (VoIP), and site-to-site traffic can all utilize this single entry point to the public network. In environments where a site-to-site VPN is the only interconnect between customer sites and the headquarter site, this link becomes even more vital.

Traditionally, multiple devices with discreet configurations have been used to provide redundancy at this network layer with mixed results. In these configurations, the enterprise relies on routing and redundancy protocols to enable a highly available and redundant customer edge. These protocols are often slow to recognize failure and do not typically allow for the synchronization required to properly handle stateful traffic. Given that a fair amount of enterprise traffic passing through the edge (to/from the Internet, or between customer sites) is stateful, a consistent challenge in the configuration of this network tier has been ensuring session state is not lost when failover or reversion occurs.

Another challenge in configuration of redundant devices is the need to configure, manage, and maintain separate physical devices with different configurations. Synchronizing those configurations can also be a challenge because as the need and complexity of security measures increase, so too does the probability that configurations are mismatched. In a secure environment, a mismatched configuration can cause something as simple as a loss of connectivity or as complex and costly as a total security breech. Any anomalous event on the customer edge can affect uptime, which consequently impacts the ability to service customers, or possibly the ability to keep customer data secure.

An answer to the problem of redundant customer edge configuration is to introduce a state-aware clustering architecture that allows two or more devices to operate as a single device. Devices in this type of architecture are able to share session information between all devices to allow for near instantaneous failover and reversion of stateful traffic. A key measure of success in this space is the ability of the cluster to fail over and revert traffic while maintaining the state of active sessions.

Using the SRX Chassis Cluster configuration described in Example: Configuring an SRX Series Services Gateway as a Full Mesh Chassis Cluster will reduce system downtime.

Devices in an effective clustering architecture can also be managed as a single device; sharing a single control plane. This function is vital as it reduces the OpEx associated with managing multiple devices. Rather than managing and operating separate devices with different configurations and management portals, you can manage multiple devices that serve the same function through a single management point.

Finally, in a cluster configuration, devices have the ability to monitor active interfaces to determine their service state. An effective cluster proactively monitors all revenue interfaces and should fail over to backup interfaces if a failure is detected. This should be done at nearly instantaneous intervals to minimize the impact of a service failure (dropped customer calls, and so on).