Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Chassis Cluster Control Plane Interfaces

 

SRX Series devices in a chassis cluster use the control plane to synchronize the kernel state between the two Routing Engines. The control interfaces provide the link between the two nodes in the cluster, which are used for by devices’ control planes communicate for the session state, the configuration file, and liveliness signals across the nodes.

The control plane software, which operates in active or backup mode, is an integral part of Junos OS that is active on the primary node of a cluster. It achieves redundancy by communicating state, configuration, and other information to the inactive Routing Engine on the secondary node. If the master Routing Engine fails, the secondary one is ready to assume control.

The control plane software:

  • Runs on the Routing Engine and oversees the entire chassis cluster system, including interfaces on both nodes

  • Manages system and data plane resources, including the Packet Forwarding Engine (PFE) on each node

  • Synchronizes the configuration over the control link

  • Establishes and maintains sessions, including authentication, authorization, and accounting (AAA) functions

  • Manages application-specific signaling protocols

  • Establishes and maintains management sessions, such as Telnet connections

  • Handles asymmetric routing

  • Manages routing state, Address Resolution Protocol (ARP) processing, and Dynamic Host Configuration Protocol (DHCP) processing

Information from the control plane software follows two paths:

  • On the primary node (where the Routing Engine is active), control information flows from the Routing Engine to the local Packet Forwarding Engine.

  • Control information flows across the control link to the secondary node's Routing Engine and Packet Forwarding Engine.

The control plane software running on the master Routing Engine maintains state for the entire cluster, and only processes running on its node can update state information. The master Routing Engine synchronizes state for the secondary node and also processes all host traffic.

Understanding Chassis Cluster Control Links

The control interfaces provide the control link between the two nodes in the cluster and are used for routing updates and for control plane signal traffic, such as heartbeat and threshold information that triggers node failover. The control link is also used to synchronize the configuration between the nodes. When you submit configuration statements to the cluster, the configuration is automatically synchronized over the control link.

The control link relies on a proprietary protocol to transmit session state, configuration, and liveliness signals across the nodes.

Starting in Junos OS Release 19.3R1, the SRX5K-RE3-128G is supported along with SRX5K-SPC3 on the SRX5000 series devices. The control interfaces ixlv0 and igb0 are used to configure SRX5K-RE3-128G.Control links control the communication between the control, and data plane and the heartbeat messages.

Note

For a single control link in a chassis cluster, the same control port should be used for the control link connection and for configuration on both nodes. For example, if port 0 is configured as a control port on node 0, then port 0 should be configured as a control port on node 1 with a cable connection between the two ports. For dual control links, control port 0 on node 0 should be connected to control port 0 on node 1 and control port 1 should be connected to control port 1 on node 1. Cross connections, that is, connecting port 0 on one node to port 1 on the other node and vice versa, do not work.

The existing control link access is enhanced to prevent hackers from logging into the system without authentication through the control link with Telnet access disabled. Chassis cluster control link supports an optional encrypted security feature that you can configure and activate. Using IPsec for internal communication between devices, the configuration information that passes through the chassis cluster link from the primary node to the secondary node is encrypted. Without the internal IPsec key, an attacker cannot gain privilege access or observe traffic. To enable this feature, run the set security ipsec internal security-association manual encryption ike-ha-link-encryption enable configuration command. You must reboot both the nodes for active this configuration.

Encryption on HA control link using IPsec in supported on, SRX4600, SRX5000 line devices, and on vSRX platforms.

When the cluster is running with the key configured already, then you can make any changes to the key without rebooting the device. In this case, you will have to change the key only on one node. But, when iked encryption is configured and whenever any configuration is changed under internal SA hierarchy, you must reboot both the nodes. The configured IKE HA link encryption algorithm can be verified in the output of show security internal-security-association

Control ports supported on SRX Series devices are:

  • By default, all control ports are disabled on SRX5400, SRX5600, and SRX5800 devices. Each SPC in a device has two control ports, and each device can have multiple SPCs plugged into it. To set up the control link in a chassis cluster with SRX5600 or SRX5800 devices, you connect and configure the control ports that you use on each device (fpc<n> and fpc<n>), and then initialize the device in cluster mode.

  • For SRX4600 devices, dedicated chassis cluster (HA) control ports and fabric ports are available. No control link configuration is needed for SRX4600 devices; however, you need to configure fabric link explicitly for chassis cluster deployments. If you want to configure 1-Gigabit Ethernet interfaces for the control ports, you must explicitly set the speed using the operational CLI command statement, set chassis cluster control-port speed 1g. See speed (Chassis Cluster) for more details.

  • For SRX4100 and SRX4200 devices, there are dedicated chassis cluster (HA) control ports available. No control link configuration is needed for SRX4100 and SRX4200 devices. For more information about all SRX4100 and SRX4200 ports including dedicated control and fabric link ports, see Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming.

    Note

    For SRX4100 and SRX4200 devices, when devices are not in cluster mode, dedicated HA ports cannot be used as revenue ports or traffic ports.

  • SRX1500 devices use the dedicated control port.

  • For SRX300, SRX320, SRX340, SRX345, SRX380 and SRX550M devices, the control link uses the ge-0/0/1 interface.

  • For SRX240, SRX550M, and SRX650 devices, the control link uses the ge-0/0/1 interface.

  • For SRX220 devices, the control link uses the ge-0/0/7 interface.

  • For SRX100 and SRX210 devices, the control link uses the fe-0/0/7 interface.

For details about port and interface usage for management, control, and fabric links, see Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming.

Example: Configuring Chassis Cluster Control Ports

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

Requirements

Before you begin:

Overview

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

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

  • FPC 4, port 0

  • FPC 10, port 0

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 the control link 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.

Verifying Chassis Cluster Control Plane Statistics

Purpose

Display chassis cluster control plane statistics.

Action

From the CLI, enter the show chassis cluster control-plane statistics command:

{primary:node1}
user@host> show chassis cluster control-plane statistics
{primary:node1}
user@host> show chassis cluster control-plane statistics

Clearing Chassis Cluster Control Plane Statistics

To clear displayed chassis cluster control plane statistics, enter the clear chassis cluster control-plane statistics command from the CLI:

{primary:node1}
user@host> clear chassis cluster control-plane statistics
Release History Table
Release
Description
Starting in Junos OS Release 19.3R1, the SRX5K-RE3-128G is supported along with SRX5K-SPC3 on the SRX5000 series devices. The control interfaces ixlv0 and igb0 are used to configure SRX5K-RE3-128G.Control links control the communication between the control, and data plane and the heartbeat messages.