ON THIS PAGE
Chassis Cluster Dual Control Links
This topic explains how dual control links provide a redundant link for controlling network traffic.
Use Feature Explorer to confirm platform and release support for specific features.
Review the Platform-Specific Dual Control Links Behavior section for notes related to your platform.
Dual Control Links Overview
A control link connects two Firewalls and carries chassis cluster control traffic, including heartbeat messages and configuration synchronization. Because the control link is a single point of failure, if it goes down, the secondary firewallnode is disabled from the cluster.
Dual control links eliminate this single point of failure by providing redundancy. In a dual control link configuration, two control interfaces connect each device in the cluster, providing a backup path for control traffic. Dual control links provide a redundant link for controlling traffic. Unlike dual fabric links, only one control link is active at any given time.
Previously, disabling the control and fabric links required manually disconnecting the cables .
The CLI commands work as follows:
In configuration mode:
To disable the control link, run the
set chassis cluster control-interface <node0/node1> disableon node 0 or node 1.When you disable the control link using this configuration command, the links remain disabled even after a system reboot.
To reenable the control link, run the
delete chassis cluster control-interface <node0/node1> disablecommand on both nodes.
In operational mode:
To disable the control link from the local node, run the
request chassis cluster control-interface <node0/node1> disablecommand.When you disable the control link using this operational mode CLI command, the link is reenabled after a system reboot.
To enable the control link on a local node, run the
request chassis cluster control-interface <node0/node1> enablecommand.
Benefit of Dual Control Links
Dual control links eliminate a single point of failure by providing a redundant path for control traffic.
Dual Control Link Functionality Requirements
In a chassis cluster with dual control links, the control links must be directly connected between the nodes. Cross connections—for example, connecting port 0 on one node to port 1 on the other node—are not supported.
When configuring dual control links, you must make the following connections:
Connect control port 0 on node 0 to control port 0 on node 1.
Connect control port 1 on node 0 to control port 1 on node 1.
For Firewallsthe SRX5600 Firewall and SRX5800 Firewall, dual control link functionality requires a second Routing Engine and a second Switch Control Board (SCB) to be installed on each device in the cluster. The second Routing Engine, which resides on the second SCB, is used to initialize the switch on the primary SCB and must be running Junos OS. A second Routing Engine is required on each device when dual control links are used.
The second Routing Engine does not provide backup functionality and does not need to be upgraded when the software on the primary Routing Engine is upgraded. For more information, see knowledge base article KB30371.
Note the following conditions:
You can run CLI commands and enter configuration mode only on the primary Routing Engine.
You configure the chassis ID and cluster ID only on the primary Routing Engine.
To verify that the second Routing Engine boots successfully or to upgrade its software image, you must connect to it through a console connection.
As long as the primary Routing Engine is installed—even if it reboots or fails— the second Routing Engine cannot assume the chassis primary role and cannot control any hardware in the chassis.
A redundancy group 0 failover results in a Routing Engine failover. During a Routing Engine failover, all processes running on the primary node are terminated and then restarted on the new primary Routing Engine. This process can lead to loss of state, such as routing information, and may temporarily degrade performance due to increased system churn.
See Also
Dual Control Link Connections for Firewalls
You can configure dual control links between SRX5600 and SRX5800 devices to reduce the risk of control link failure. On supported platforms, you can also configure dual fabric links in addition to dual control links to further improve resiliency against both control and fabric link failures.
Junos OS does not support dual control links on SRX5400 devices, due to the limited number of slots.
On SRX5800 devices, dual control links are configured using Services Processing Cards (SPCs). Two SPC3 cards are required per node to support dual control links. For redundancy, it is recommended that the primary and secondary control ports be placed on different SPCs on each node.
For SRX5600 devices and SRX5800 devices, you must connect two pairs of identical Ethernet ports to form dual control links. Although control ports can be connected on the same SPC, it is recommended to connect them across two different SPCs for improved redundancy.
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. Cross‑connecting control ports (for example, connecting control port 0 to control port 1) is not supported and prevents heartbeat packets from being exchanged between the nodes.
See Also
Upgrade the Second Routing Engine When Using Chassis Cluster Dual Control Links on SRX5600 and SRX5800 Devices
Use the primary Routing Engine to create a bootable USB storage device. You can then use this USB device to install a software image on the second Routing Engine.
To upgrade the software image on the second Routing Engine:
Example: Configure Chassis Cluster Control Ports for Dual Control Links
This example shows how to configure chassis cluster control ports for use as dual control links on SRX5600 devices and SRX5800 devices. You need to configure the control ports that you will use on each device to set up the control links.
Requirements
Before you begin:
Understand chassis cluster control links. See Understanding Chassis Cluster Control Plane and Control Links.
Physically connect the control ports on the devices. See Connecting SRX Series Devices to Create a Chassis Cluster.
Overview
By default, all control ports on SRX5600 devices and SRX5800 devices are disabled. After the control ports are connected, configured, and the chassis cluster is established, the control links become operational.
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
Procedure
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.
{primary:node0}[edit]
set chassis cluster control-ports fpc 4 port 0
set chassis cluster control-ports fpc 10 port 0
set chassis cluster control-ports fpc 6 port 1
set chassis cluster control-ports fpc 12 port 1
Step-by-Step Procedure
To configure control ports for use as dual control links for the chassis cluster:
Specify the control ports.
{primary:node0}[edit]
user@host# set chassis cluster control-ports fpc 4 port 0
{primary:node0}[edit]
user@host# set chassis cluster control-ports fpc 10 port 0
{primary:node0}[edit]
user@host# set chassis cluster control-ports fpc 6 port 1
{primary:node0}[edit]
user@host# set chassis cluster control-ports fpc 12 port 1
Results
In 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 (...).
{primary:node0}[edit]
user@host# show chassis cluster
...
control-ports {
fpc 4 port 0;
fpc 6 port 1;
fpc 10 port 0;
fpc 12 port 1;
}
...
If you are finished configuring the device, enter commit from configuration
mode.
Verification
Verification of the Chassis Cluster Status
Purpose
Verify the chassis cluster status.
Action
In operational mode, enter the show chassis cluster status command.
{primary:node0}
user@host> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 100 primary no no
node1 1 secondary no no
Redundancy group: 1 , Failover count: 1
node0 0 primary no no
node1 0 secondary no no
Meaning
Use the show chassis cluster status command to confirm that the devices in the chassis cluster are communicating with each other. The output shows that the chassis cluster is functioning properly, as one device is the primary node and the other is the secondary node.
Platform-Specific Dual Control Links Behavior
Use Feature Explorer to confirm platform and release support for specific features.
Use the following table to review platform-specific behaviors for your platform.
|
Platform |
Difference |
|---|---|
|
SRX Series |
|
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.