Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Chassis Clustering on SRX Series Devices

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 device to provide high availability. 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.

For SRX300, SRX320, SRX340, SRX345, and SRX380 devices, connect ge-0/0/1 on node 0 to ge-0/0/1 on node 1. The factory-default configuration does not include HA configuration. To enable HA, if the physical interfaces used by HA have some configurations, these configurations need to be removed. Table 1 lists the physical interfaces used by HA on SRX300, SRX320, SRX340, SRX345, and SRX380.

Table 1: Mapping Between HA Interface and Physical Interface on SRX300, SRX320, SRX340, SRX345, and SRX380

Device

fxp0 Interface (HA MGT)

fxp1 Interface (HA Control)

Fab Interface

SRX300

ge-0/0/0

ge-0/0/1

User defined

SRX320

ge-0/0/0

ge-0/0/1

User defined

SRX340

dedicated

ge-0/0/1

User defined

SRX345

dedicated

ge-0/0/1

User defined

SRX380

dedicated

ge-0/0/1

User defined

For more information, see the following topics:

Example: Configure Chassis Clustering on SRX Series Firewalls

This example shows how to set up chassis clustering on an SRX Series Firewall (using SRX1500 or SRX1600 as example).

Requirements

Before you begin:

  • Physically connect the two devices and ensure that they are the same models. For example, on the SRX1500 or SRX1600 Firewall, connect the dedicated control ports on node 0 and node 1.

  • Set the two devices to cluster mode and reboot the devices. You must enter the following operational mode commands on both devices, for example:

    • On node 0:

    • On node 1:

    The cluster-id is the same on both devices, but the node ID must be different because one device is node 0 and the other device is node 1. The range for the cluster-id is 0 through 255 and setting it to 0 is equivalent to disabling cluster mode.

  • After clustering occurs for the devices, continuing with the SRX1500 or SRX1600 Firewall example, the ge-0/0/0 interface on node 1 changes to ge-7/0/0.

    After clustering occurs,

    • For SRX300 devices, the ge-0/0/1 interface on node 1 changes to ge-1/0/1.

    • For SRX320 devices, the ge-0/0/1 interface on node 1 changes to ge-3/0/1.

    • For SRX340 and SRX345 devices, the ge-0/0/1 interface on node 1 changes to ge-5/0/1.

    After the reboot, the following interfaces are assigned and repurposed to form a cluster:

    • For SRX300 and SRX320 devices, ge-0/0/0 becomes fxp0 and is used for individual management of the chassis cluster.

    • SRX340 and SRX345 devices contain a dedicated port fxp0.

    • For all SRX300, SRX320, SRX340, SRX345, and SRX380 devices, ge-0/0/1 becomes fxp1 and is used as the control link within the chassis cluster.

    • The other interfaces are also renamed on the secondary device.

    See Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming for complete mapping of the SRX Series Firewalls.

From this point forward, configuration of the cluster is synchronized between the node members and the two separate devices function as one device.

Overview

This example shows how to set up chassis clustering on an SRX Series Firewall using the SRX1500 or SRX1600 device as example.

The node 1 renumbers its interfaces by adding the total number of system FPCs to the original FPC number of the interface. See Table 2 for interface renumbering on the SRX Series Firewall.

Table 2: SRX Series Firewalls Interface Renumbering

SRX Series Services Gateway

Renumbering Constant

Node 0 Interface Name

Node 1 Interface Name

SRX300

1

ge-0/0/0

ge-1/0/0

SRX320

3

ge-0/0/0

ge-3/0/0

SRX340

SRX345

SRX380

5

ge-0/0/0

ge-5/0/0

SRX1500

7

ge-0/0/0

ge-7/0/0

SRX1600

7

ge-0/0/0

ge-7/0/0

After clustering is enabled, the system creates fxp0, fxp1, and em0 interfaces. Depending on the device, the fxp0, fxp1, and em0 interfaces that are mapped to a physical interface are not user defined. However, the fab interface is user defined.

Figure 1 shows the topology used in this example.

Figure 1: SRX Series Firewalls (SRX1500) In Chassis ClusterSRX Series Firewalls (SRX1500) In Chassis Cluster

Configuration

Procedure

CLI Quick Configuration

To quickly configure a chassis cluster on an SRX1500 Firewall, copy the following commands and paste them into the CLI:

On {primary:node0}

If you are configuring SRX300, SRX320, SRX340, SRX345, and SRX380 devices, see Table 3 for command and interface settings for your device and substitute these commands into your CLI.

Table 3: SRX Series Firewalls Interface Settings

Command

SRX300

SRX320

SRX340

SRX345

SRX380

set interfaces fab0 fabric-options member-interfaces

ge-0/0/2

ge-0/0/2

ge-0/0/2

set interfaces fab1 fabric-options member-interfaces

ge-1/0/2

ge-3/0/2

ge-5/0/2

set chassis cluster redundancy-group 1 interface-monitor

ge-0/0/3 weight 255

ge-0/0/3 weight 255

ge-0/0/3 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-0/0/4 weight 255

ge-0/0/4 weight 255

ge-0/0/4 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-1/0/3 weight 255

ge-3/0/3 weight 255

ge-5/0/3 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-1/0/4 weight 255

ge-3/0/4 weight 255

ge-5/0/4 weight 255

set interfaces

ge-0/0/3 gigether-options redundant-parent reth0

ge-0/0/3 gigether-options redundant-parent reth0

ge-0/0/3 gigether-options redundant-parent reth0

set interfaces

ge-0/0/4 gigether-options redundant-parent reth1

ge-0/0/4 gigether-options redundant-parent reth1

ge-0/0/4 gigether-options redundant-parent reth1

set interfaces

ge-1/0/3 gigether-options redundant-parent reth0

ge-3/0/3 gigether-options redundant-parent reth0

ge-5/0/3 gigether-options redundant-parent reth0

set interfaces

ge-1/0/4 gigether-options redundant-parent reth1

ge-3/0/4 gigether-options redundant-parent reth1

ge-5/0/4 gigether-options redundant-parent reth1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a chassis cluster on an SRX Series Firewall:

Perform Steps 1 through 5 on the primary device (node 0). They are automatically copied over to the secondary device (node 1) when you execute a commit command. The configurations are synchronized because the control link and fab link interfaces are activated. To verify the configurations, use the show interface terse command and review the output.

  1. Set up hostnames and management IP addresses for each device using configuration groups. These configurations are specific to each device and are unique to its specific node.

    Set the default route and backup router for each node.

    Set the apply-group command so that the individual configurations for each node set by the previous commands are applied only to that node.

  2. Define the interfaces used for the fab connection (data plane links for RTO sync) by using physical ports ge-0/0/1 from each node. These interfaces must be connected back-to-back, or through a Layer 2 infrastructure.

  3. Set up redundancy group 0 for the Routing Engine failover properties, and set up redundancy group 1 (all interfaces are in one redundancy group in this example) to define the failover properties for the redundant Ethernet interfaces.

  4. Set up interface monitoring to monitor the health of the interfaces and trigger redundancy group failover.

    We do not recommend Interface monitoring for redundancy group 0 because it causes the control plane to switch from one node to another node in case interface flap occurs.

    Interface failover only occurs after the weight reaches 0.

  5. Set up the redundant Ethernet (reth) interfaces and assign the redundant interface to a zone.

Results

From operational mode, confirm your configuration by entering the show configuration command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Chassis Cluster Status

Purpose

Verify the chassis cluster status, failover status, and redundancy group information.

Action

From operational mode, enter the show chassis cluster status command.

Verifying Chassis Cluster Interfaces

Purpose

Verify information about chassis cluster interfaces.

Action

From operational mode, enter the show chassis cluster interfaces command.

Verifying Chassis Cluster Statistics

Purpose

Verify information about the statistics of the different objects being synchronized, the fabric and control interface hellos, and the status of the monitored interfaces in the cluster.

Action

From operational mode, enter the show chassis cluster statistics command.

Verifying Chassis Cluster Control Plane Statistics

Purpose

Verify information about chassis cluster control plane statistics (heartbeats sent and received) and the fabric link statistics (probes sent and received).

Action

From operational mode, enter the show chassis cluster control-plane statistics command.

Verifying Chassis Cluster Data Plane Statistics

Purpose

Verify information about the number of RTOs sent and received for services.

Action

From operational mode, enter the show chassis cluster data-plane statistics command.

Verifying Chassis Cluster Redundancy Group Status

Purpose

Verify the state and priority of both nodes in a cluster and information about whether the primary node has been preempted or whether there has been a manual failover.

Action

From operational mode, enter the chassis cluster status redundancy-group command.

Troubleshooting with Logs

Purpose

Use these logs to identify any chassis cluster issues. You should run these logs on both nodes.

Action

From operational mode, enter these show log commands.

Viewing a Chassis Cluster Configuration

Purpose

Display chassis cluster verification options.

Action

From the CLI, enter the show chassis cluster ? command:

Viewing Chassis Cluster Statistics

Purpose

Display information about chassis cluster services and interfaces.

Action

From the CLI, enter the show chassis cluster statistics command:

Clearing Chassis Cluster Statistics

To clear displayed information about chassis cluster services and interfaces, enter the clear chassis cluster statistics command from the CLI:

Understanding Automatic Chassis Cluster Synchronization Between Primary and Secondary Nodes

When you set up an SRX Series chassis cluster, the SRX Series Firewalls must be identical, including their configuration. The chassis cluster synchronization feature automatically synchronizes the configuration from the primary node to the secondary node when the secondary joins the primary as a cluster. By eliminating the manual work needed to ensure the same configurations on each node in the cluster, this feature reduces expenses.

If you want to disable automatic chassis cluster synchronization between the primary and secondary nodes, you can do so by entering the set chassis cluster configuration-synchronize no-secondary-bootup-auto command in configuration mode.

At any time, to reenable automatic chassis cluster synchronization, use the delete chassis cluster configuration-synchronize no-secondary-bootup-auto command in configuration mode.

To see whether the automatic chassis cluster synchronization is enabled or not, and to see the status of the synchronization, enter the show chassis cluster information configuration-synchronization operational command.

Either the entire configuration from the primary node is applied successfully to the secondary node, or the secondary node retains its original configuration. There is no partial synchronization.

If you create a cluster with cluster IDs greater than 16, and then decide to roll back to a previous release image that does not support extended cluster IDs, the system comes up as standalone.

If you have a cluster set up and running with an earlier release of Junos OS, you can upgrade to Junos OS Release 12.1X45-D10 and re-create a cluster with cluster IDs greater than 16. However, if for any reason you decide to revert to the previous version of Junos OS that did not support extended cluster IDs, the system comes up with standalone devices after you reboot. However, if the cluster ID set is less than 16 and you roll back to a previous release, the system will come back with the previous setup.

Verifying Chassis Cluster Configuration Synchronization Status

Purpose

Display the configuration synchronization status of a chassis Understanding Automatic Chassis Cluster Synchronization Between Primary and Secondary Nodescluster.

Action

From the CLI, enter the show chassis cluster information configuration-synchronization command: