Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Chassis Cluster Dual Control Links

 

Dual control links provide a redundant link for control traffic. For more information, see the following topics:

The control link connects two SRX Series devices together and it is responsible for sending high-availability control data between the two SRX Series devices including heartbeats and configuration synchronization. If this link goes down, the secondary SRX Series is disabled from the cluster. In dual control links, two pairs of control link interfaces are connected between each device in a cluster. Having two control links helps to avoid a possible single point of failure. Dual control links, provide a redundant link for control traffic. Unlike dual fabric links, only one control link is used at any one time.

Dual control links are supported for the SRX4600, SRX5600 and SRX5800 Services Gateways.

Note

For the SRX5400 Services Gateways, dual control is not supported due to limited slots.

Note

Dual control link functionality is not supported on SRX4100 and SRX4200 devices.

Benefits of Dual Control Links

  • Provides a redundant link for control traffic. In the link-level redundancy, if one link fails, the other can take over and restore traffic forwarding that had been previously sent over the failed link.

  • Prevents the possibility of single point of failure.

Dual Control Links Functionality Requirements

For the SRX5600 and SRX5800 Services Gateways, dual control link functionality requires a second Routing Engine, as well as a second Switch Control Board (SCB) to house the Routing Engine, to be installed on each device in the cluster. The purpose of the second Routing Engine is only to initialize the switch on the SCB.

Note

For the SRX5000 line, the second Routing Engine must be running Junos OS Release 10.0 or later.

The second Routing Engine, to be installed on SRX5000 line devices only, does not provide backup functionality. It does not need to be upgraded, even when there is a software upgrade of the master Routing Engine on the same node. Note the following conditions:

  • You cannot run the CLI or enter configuration mode on the second Routing Engine.

  • You do not need to set the chassis ID and cluster ID on the second Routing Engine.

  • You need only a console connection to the second Routing Engine. (A console connection is not needed unless you want to check that the second Routing Engine booted up or to upgrade a software image.)

  • You cannot log in to the second Routing Engine from the master Routing Engine.

Note

As long as the first Routing Engine is installed (even if it is rebooting or failing), the second Routing Engine cannot take over the chassis mastership; that is, it cannot control all the hardware on the chassis.

Caution

Be cautious and judicious in your use of redundancy group 0 manual failovers. A redundancy group 0 failover implies a Routing Engine (RE) failover, in which case all processes running on the primary node are killed and then spawned on the new master Routing Engine (RE). This failover could result in loss of state, such as routing state, and degrade performance by introducing system churn.

Note

For the SRX3000 line, dual control link functionality requires an SRX Clustering Module (SCM) to be installed on each device in the cluster. Although the SCM fits in the Routing Engine slot, it is not a Routing Engine. SRX3000 line devices do not support a second Routing Engine. The purpose of the SCM is to initialize the second control link.

For SRX5600 and SRX5800 devices, you can connect two control links between the two devices, effectively reducing the chance of control link failure.

Dual control links are not supported on SRX5400 due to the limited number of slots.

For SRX5600 and SRX5800 devices, connect two pairs of the same type of Ethernet ports. For each device, you can use ports on the same Services Processing Card (SPC), but we recommend that they be on two different SPCs to provide high availability. Figure 1 shows a pair of SRX5800 devices with dual control links connected. In this example, control port 0 and control port 1 are connected on different SPCs.

Figure 1: Connecting Dual Control Links (SRX5800 Devices)
 Connecting Dual Control Links (SRX5800 Devices)
Note

For SRX5600 and SRX5800 devices, you must connect control port 0 on one node to control port 0 on the other node and, likewise, control port 1 to control port 1. If you connect control port 0 to control port 1, the nodes cannot receive heartbeat packets across the control links.

For SRX5600 and SRX5800 devices, a second Routing Engine is required for each device in a cluster if you are using dual control links. The second Routing Engine does not provide backup functionality; its purpose is only to initialize the switch on the Switch Control Board (SCB). The second Routing Engine must be running Junos OS Release 12.1X47-D35, 12.3X48-D30, 15.1X49-D40 or later. For more information, see knowledge base article KB30371.

Note

On SRX5600 and SRX5800 devices, starting from Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, you can use the show chassis hardware command to see the serial number and the hardware version details of the second Routing Engine. To use this functionality, ensure that the second Routing Engine is running Junos OS Release 15.1X49-D70 and later releases or Junos OS Release 17.3R1 or later releases.

Note

For the SRX5400 Services Gateways, dual control is not supported due to limited slots.

Because you cannot run the CLI or enter configuration mode on the second Routing Engine, you cannot upgrade the Junos OS image with the usual upgrade commands. Instead, use the master Routing Engine to create a bootable USB storage device, which you can then use to install a software image on the second Routing Engine.

To upgrade the software image on the second Routing Engine:

  1. Use FTP to copy the installation media into the /var/tmp directory of the master Routing Engine.
  2. Insert a USB storage device into the USB port on the master Routing Engine.
  3. In the UNIX shell, navigate to the /var/tmp directory:
  4. Log in as root or superuser:
  5. Issue the following command:

    where

    • externalDrive—Refers to the removable media name. For example, the removable media name on an SRX5000 line device is da0 for both Routing Engines.

    • installMedia—Refers to the installation media downloaded into the /var/tmp directory. For example, install-media-srx5000-10.1R1-domestic.img.

    The following code example can be used to write the image that you copied to the master Routing Engine in step 1 onto the USB storage device:

  6. Log out as root or superuser:
  7. After the software image is written to the USB storage device, remove the device and insert it into the USB port on the second Routing Engine.
  8. Move the console connection from the master Routing Engine to the second Routing Engine, if you do not already have a connection.
  9. Reboot the second Routing Engine. Issue the following command (for Junos OS Release 15.1X49-D65 and earlier):

    Starting with Junos OS Release 15.1X49-D70, issue the following command:

    • When the following system output appears, press y:

    • When the following system output appears, remove the USB storage device and press Enter:

This example shows how to configure chassis cluster control ports for use as dual control links on SRX5600, and SRX5800 devices. You need to configure the control ports that you will use on each device to set up the control links.

Note

Dual control links are not supported on an SRX5400 device due to the limited number of slots.

Requirements

Before you begin:

Overview

By default, all control ports on SRX5600 and SRX5800 devices are disabled. After connecting the control ports, configuring the control ports, and establishing the chassis cluster, the control links are set up.

This example configures control ports with the following FPCs and ports as the dual control links:

  • FPC 4, port 0

  • FPC 10, port 0

  • FPC 6, port 1

  • FPC 12, port 1

Configuration

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure control ports for use as dual control links for the chassis cluster:

  • Specify the control ports.

Results

From configuration mode, confirm your configuration by entering the show chassis cluster 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

Verifying the Chassis Cluster Status

Purpose

Verify the chassis cluster status.

Action

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

{primary:node0}
user@host> show chassis cluster status

Meaning

Use the show chassis cluster status command to confirm that the devices in the chassis cluster are communicating with each other. The chassis cluster is functioning properly, as one device is the primary node and the other is the secondary node.