Chassis Cluster Control Plane Interfaces
This topic explains how to use control plane interfaces to synchronize kernel state between Routing Engines on Firewalls in a chassis cluster. Control plane interfaces provide the communication link between the two nodes in the cluster.
Use Feature Explorer to confirm platform and release support for specific features.
Control plane interfaces use the control link to:
-
Communicate node discovery information.
-
Maintains session state for the cluster.
-
Access the configuration file.
-
Detect node liveliness through hearbeat signals.
Control Plane and Control Links
See the Additional Platform Information section for more information.
The control plane software operates either in active or backup mode and is a core component of Junos OS running on the primary node of a cluster. It provides redundancy by synchronizing system state, configuration, and other information with the inactive Routing Engine on the secondary node. If the primary Routing Engine fails, the secondary Routing Engine is fully prepared to take over control without service disruption.
The control plane software performs the following functions:
Runs on the Routing Engine.
Monitors and controls 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 data between nodes over the control link.
Establishes and maintains sessions, for authentication, authorization, and accounting (AAA) functions.
Supports and manages application-specific signaling protocols.
Establishes and maintains management sessions, such as Telnet connections.
Handles asymmetric routing on the chassis cluster nodes.
Maintains routing state, Address Resolution Protocol (ARP), and Dynamic Host Configuration Protocol (DHCP) processing.
Control plane information flows through the system in the following ways:
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 is also transmitted across the control link to the secondary node's Routing Engine and Packet Forwarding Engine.
The control plane software running on the primary Routing Engine maintains state for the entire chassis cluster. Only processes running on the same node as the control plane software are permitted to update state information. The primary Routing Engine synchronizes state for the secondary node and processes all host traffic.
Chassis Cluster Control Links
The chassis cluster control link provides the communication path required for coordination and high availability between nodes in a chassis cluster.
Facilitates communication between the control plane, data plane, and heartbeat messages.
Uses control interfaces to connect the two nodes in a chassis cluster.
Exchanges routing updates and control plane signaling, including heartbeat messages and threshold information that can trigger node failover.
Synchronizes configuration data between nodes. When configuration statements are committed on the cluster, they are automatically propogated to the peer node over the control link.
Uses a proprietary protocol to transmit session state, configuration information, and liveliness information between the nodes.
Single Control Link in a Chassis Cluster
When deploying a single control link in a chassis cluster, you must use the same control port on both nodes.
For example, if port 0 is configured as the control port on node 0, port 0 must also be configured as the control port on node 1. The two ports must be directly connected using a dedicated cable.
Encryption on the Chassis Cluster Control Link
Chassis cluster control links support an optional encryption feature that you can configure and enable inter-node communication.
Note that Juniper Networks security documentation uses chassis cluster when referring to high availability (HA) control links. You will still see the abbreviation ha used in place of chassis cluster in commands.
When Telnet access is disabled, the control link helps prevent unauthorized users from logging in to the system.
By using an internal IPsec key for interdevice communication, configuration information transmitted over the chassis cluster control link from the primary node to the secondary node is encrypted. Without the IPsec key, an attacker cannot view or access this traffic.
To enable encryption on the chassis cluster control link, run the following configuration command:
set security ipsec internal security-association manual encryption ike-ha-link-encryption enable
After enabling this feature, you must reboot both nodes for the configuration to take effect.
Encryption on chassis cluster control link using IPsec is supported on SRX4600 Firewall, SRX5000 line of Firewalls, and vSRX Virtual Firewall.
If the chassis cluster is already operational with an IPsec key configured, you can modify the key without rebooting the devices. In this case, the key needs to be changed on only one node.
however, when IPsec key encryption is configured, any configuration changes made under the internal security association (SA) hierarchy require a reboot of both nodes.
To verify the configured Internet Key Exchange (IKE) encryption algorithm used for the chassis cluster control link, use the following command:
show security internal-security-association
Example: Configure Chassis Cluster Control Ports for Control Link
This example shows how to configure chassis cluster control ports on SRX5000 line of Firewalls . You must configure the control ports on each device to establish the control link.
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
Control link traffic passes through the switches in the Services Processing Cards (SPCs) and reaches the peer node. On Firewalls, chassis cluster ports are located on the SPCs . By default, all control ports on SRX5000 line of Firewalls are disabled. To establish the control links, you must connect and configure the control ports, and then set up the chassis cluster.
This example configures control ports with the following Flexible PIC Concentrators (FPCs) and ports as the control link:
- FPC 4, port 0
- FPC 10, port 0
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 in configuration mode.
{primary:node0}[edit]
set chassis cluster control-ports fpc 4 port 0
set chassis cluster control-ports fpc 10 port 0
{primary:node1}[edit]
set chassis cluster control-ports fpc 4 port 0
set chassis cluster control-ports fpc 10 port 0Step-by-Step Procedure
To configure control ports as the control link 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:node1}[edit]
user@host# set chassis cluster control-ports fpc 4 port 0
{primary:node1}[edit]
user@host# set chassis cluster control-ports fpc 10 port 0
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 (...).
user@host# show chassis cluster
...
control-ports {
fpc 4 port 0;
fpc 10 port 0;
}
...After you configure the device, enter commit in configuration mode.
Verify 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 noMeaning
Use the show chassis cluster status command to confirm that the devices in the chassis cluster are communicating with each other. The preceding output shows that chassis cluster is functioning properly, as one device is the primary node and the other is the secondary node.
Verify Chassis Cluster Control Plane Statistics
Purpose
Display chassis cluster control plane statistics.
Action
At the CLI, enter the show chassis cluster control-plane
statistics command:
{primary:node1}
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 124
Heartbeat packets received: 125
Fabric link statistics:
Child link 0
Probes sent: 124
Probes received: 125
{primary:node1}
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Control link 1:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Fabric link statistics:
Child link 0
Probes sent: 258690
Probes received: 258690
Child link 1
Probes sent: 258505
Probes received: 258505
See Also
Clear Control Plane Statistics
To clear the
displayed chassis cluster
control plane statistics, enter the clear
chassis cluster control-plane statistics
command at the CLI:
{primary:node1}
user@host> clear chassis cluster control-plane statistics
Cleared control-plane statisticsChange from Chassis Cluster to Standalone Mode
Additional Platform Information
Use Feature Explorer to confirm platform and release support for specific features.
Additional Platforms may be supported.
| SRX Series Firewalls | Supported Control Ports |
|---|---|
|
SRX5000 line of Firewalls |
|
|
SRX4600 |
Dedicated 10-Gigabit Ethernet control ports and fabric ports are available in chassis cluster. No control link configuration is required for SRX4600 Firewalls;
however, you must explicitly configure the fabric link for
chassis cluster deployments. If you use 1-Gigabit Ethernet
interfaces as control ports, you must explicitly set the
interface speed by using an operational mode |
|
SRX4100 and SRX4200 |
Dedicated chassis cluster control ports are available. Control link configuration is not required. For more information about all SRX4100 ports and SRX4200 ports, including dedicated control links ports and fabric link ports, see Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming. When devices are not in cluster mode, dedicated chassis cluster ports cannot be used as revenue ports or traffic ports. |
|
SRX1500 |
Devices use the dedicated control port. |
|
SRX300, SRX320, SRX340, SRX345, and SRX380. |
Control link uses the ge-0/0/1 interface. |