Tuesday, March 13, 2012

Configure Chassis Cluster (High Availability) on a SRX650 device

Summary:

This article describes the basic setup of a Chassis Cluster (High Availability), also known as JSRP, on a SRX650 device.

Problem or Goal:

Configure SRX650 devices as a Chassis Cluster.

The following topology will be used for the configuration:



For other SRX devices, refer to the following articles:

SRX100 KB15669
SRX210 KB15505
SRX220 KB21312
SRX240 KB15504
SRX1400 TN10
SRX3000 series TN10
SRX5000 series TN10

Solution:

This section contains the following:


Configuration

The following are the basic steps required for configuring a Chassis Cluster on SRX650 devices. It is best to use a console connection to the SRX devices when following these steps.


Step 1. Physically connect the two devices, making sure they are the same models. On the SRX 650 device, connect ge-0/0/1 on device A to ge-0/0/1 on device B. The ge-0/0/1 interface on device B will change to ge-9/0/1 after clustering happens.

For connecting the devices, it is helpful to know that after step2, the following will interface assignments will occur:
  • ge-0/0/0 will be used as fxp0 for individual management of each of the devices
  • ge-0/0/1 will become fxp1 and used as the control link between the two devices (This is also documented in KB15356.)
  • The other interfaces are also renamed on the secondary device. For example, on a SRX 650 device, the ge-0/0/0 interface is renamed to ge-9/0/0 on the secondary node 1. Refer to the complete mapping for each SRX Series device: Node Interfaces on Active SRX Series Chassis Clusters.
Important:
The interfaces used for the control link, in this example ge-0/0/1, must be connected with a cable. A switch cannot be used for the control link connection.
Also, you will need to decide on a third link to connect the devices, which will be used for the fabric link between the devices. This can be ge-0/0/2 or any other open port either onboard or on a gPIM.

Step 2. Set the devices into cluster mode with the following command and reboot the devices. Note that this is an operational mode and not a configure mode command.

> set chassis cluster cluster-id <0-15> node <0-1> reboot
For example:
On device A: >set chassis cluster cluster-id 1 node 0 reboot
On device B: >set chassis cluster cluster-id 1 node 1 reboot
  • Cluster id will be the same on both devices, but the node id should be different as one device is node0 the other device is node1
  • This command will need to be done on both devices
  • The range for the cluster-id is 0-15. Setting it to 0 is the equivalent of disabling cluster mode.
After the reboot, note how the ge-0/0/0 and ge-0/0/1 interfaces are re-purposed to fxp0 and fxp1 respectively.

NOTE:
The following steps 3- 8 can all be performed on the primary device (Device A), and they will be automatically copied over to the secondary device (Device B) when a commit is done.

Step 3. Set up the device specific configurations such as host names and management IP addresses, this is specific to each device and is the only part of the configuration that is unique to its specific node. This is done by entering the following commands (all on the primary node):
    On device A:
    {primary:node0}
    # set group node0 system host-name -Device A's host name
    # set group node0 interfaces fxp0 unit 0 family inet address -Device A's management IP address on fxp0 interface

    # set group node1 system host-name -Device B's host name
    # set group node1 interfaces fxp0 unit 0 family inet address - Set this command is set so that the individual configs for each node set by the above commands is applied only to that node. (required)

Step 4. Create FAB links (data plane links for RTO sync, etc).

    On device A:
    {primary:node0}
    # set interfaces fab0 fabric-options member-interfaces ge-0/0/2 -fab0 is node0 (Device A) interface for the data link

    # set interfaces fab1 fabric-options member-interfaces ge-9/0/2 -fab1 is node1 (Device B) interface for the data link

Step 5. Set up the Redundancy Group 0 for the Routing Engine failover properties. Also setup Redundancy Group 1 (all the interfaces will be in one Redundancy Group in this example) to define the failover properties for the Reth interfaces.

Note: If you want to use multiple Redundancy Groups for the interfaces, refer to the Security Configuration Guide.

    {primary:node0}
    # set chassis cluster redundancy-group 0 node 0 priority 100
    # set chassis cluster redundancy-group 0 node 1 priority 1
    # set chassis cluster redundancy-group 1 node 0 priority 100
    # set chassis cluster redundancy-group 1 node 1 priority 1

Step 6. Set up the Interface monitoring. Monitoring the health of the interfaces is one way to trigger Redundancy group failover. Note: interface monitoring is not recommended for redundancy-group 0.

    On device A:
    {primary:node0}
    # set chassis cluster redundancy-group 1 interface-monitor ge-1/0/0 weight 255
    # set chassis cluster redundancy-group 1 interface-monitor ge-10/0/0 weight 255
    # set chassis cluster redundancy-group 1 interface-monitor ge-1/0/1 weight 255
    # set chassis cluster redundancy-group 1 interface-monitor ge-10/0/1 weight 255
Step 7. Setup the Redundant Ethernet interfaces (Reth interface) and assign the Redundant interface to a zone. Make sure that you setup your max number of redundant interfaces as follows:
    On device A:
    {primary:node0}
    # set chassis cluster reth-count
    # set interfaces gigether-options redundant-parent reth0 -for first interface in the group (on Device A)
    # set interfaces gigether-options redundant-parent reth0 -for second interface in the group (on Device B)

    # set interfaces reth0 redundant-ether-options redundancy-group -set up redundancy group for interfaces
    # set interfaces reth0.0 family inet address
    # set security zones security-zone interfaces reth0.0
For example:
    On device A:
    {primary:node0}
    # set chassis cluster reth-count 2
    # set interfaces ge-1/0/0 gigether-options redundant-parent reth1 -for first interface in the group (on Device A)
    # set interfaces ge-10/0/0 gigether-options redundant-parent reth1 -for second interface in the group (on Device B)
    # set interfaces reth1 redundant-ether-options redundancy-group 1 -set up redundancy group for interfaces
    # set interfaces reth1 unit 0 family inet address 1.2.0.233/24
    # set interfaces ge-1/0/1 gigether-options redundant-parent reth0 -for first interface in the group (on Device A)
    # set interfaces ge-10/0/1 gigether-options redundant-parent reth0 -for second interface in the group (on Device B)
    # set interfaces reth0 redundant-ether-options redundancy-group 1 -set up redundancy group for interfaces
    # set interfaces reth0 unit 0 family inet address 10.16.8.1/24
    # set security zones security-zone untrust interfaces reth1.0
    # set security zones security-zone trust interfaces reth0.0

Step 8. Commit and changes will be copied over to the Secondary Node, Device B.

    On device A:
    {primary:node0}
    # commit
This will prepare the basic clustering setting for both the devices.


TIP: If you want to manage this cluster via NSM, refer to KB20795.



Technical Documentation

Junos Security Configuration Guide

  • HTML - Chassis Cluster
  • PDF - Part 11 - Chassis Cluster


Verification

You can check the cluster status with the following commands.
show chassis cluster status
show chassis cluster interfaces
show chassis cluster statistics
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics
show chassis cluster status redundancy-group 2
Refer to the Junos Security Configuration Guide for what these commands mean:
  • HTML - Verifying the Chassis Cluster Configuration

Troubleshooting


Purpose:
Configuration

Related Links:

ASK THE KB

Question or KB ID: