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

For other SRX devices, refer to the following articles:
SRX 210 - KB15505
SRX 240 - KB15504
SRX 650 - KB15503
SRX 3000/5000 series - SRX High Availability Deployment Guide (Chassis Cluster configuration examples)

Topology used for this example:

The following are the basic steps required for configuring a Chassis Cluster on SRX 100 devices.  It is best to use a console connection to the SRX devices when following these steps.  More details can be found in Chapter 32 of the Security Configuration Guide, located in the JUNOS Software Documentation.                

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

For connecting the devices, it is helpful to know that after step2, the following will interface assignments will occur:

• fe-0/0/6  will be used as fxp0 for individual management of each of the devices
• fe-0/0/7 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 100 device, the fe-0/0/0 interface is renamed to fe-1/0/0 on the secondary node 1. Refer to the complete mapping for each SRX Series device in 'Table 160: SRX Series Chassis Cluster Slot Numbering and Interface Naming Example' of the Security Configuration Guide.       

Important: 
The interfaces used for the control link, in this example fe-0/0/7, 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 any available Fastethernet port other than fe-0/0/6 and fe-0/0/7.

  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 fe-0/0/6 and fe-0/0/7 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.

  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 <name-node0>      -Device A's host name
# set group node0 interfaces fxp0 unit 0 family inet address <ip address/mask>  -Device A's management IP address on fxp0 interface
# set group node1 system host-name <name-node1>      -Device B's host name
# set group node1 interfaces fxp0 unit 0 family inet address <ip address/mask   -Device B's management IP address on fxp0 interface

- This command is set so that the individual configs for each node set by the above commands is applied only to that node.
# set apply-groups "${node}"


  Create FAB links (data plane links for RTO sync, etc). For this example we will use physical ports fe-0/0/1 from each node.

On device A:
{primary:node0}
# set interfaces fab0 fabric-options member-interfaces fe-0/0/1    -fab0 is node0 (Device A) interface for the data link
# set interfaces fab1 fabric-options member-interfaces fe-1/0/1    -fab1 is node1 (Device B) interface for the data link


  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 node 0
# set chassis cluster redundancy-group 0 node 1 priority 1
# set chassis cluster node 1
# set chassis cluster redundancy-group 1 node 0 priority 100
# set chassis cluster node 0
# set chassis cluster redundancy-group 1 node 1 priority 1
# set chassis cluster node 1 


  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 fe-0/0/0 weight 255
# set chassis cluster redundancy-group 1 interface-monitor fe-0/0/2 weight 255
# set chassis cluster redundancy-group 1 interface-monitor fe-1/0/0 weight 255
# set chassis cluster redundancy-group 1 interface-monitor fe-1/0/2 weight 255

  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 <max-number>
# set interfaces <node0-interface-name> fastether-options redundant-parent reth0    -for first interface in the group (on Device A)
# set interfaces <node1-interface-name> fastether-options redundant-parent reth0    -for second interface in the group (on Device B)
# set interfaces reth0 redundant-ether-options redundancy-group <group-number>      -set up redundancy group for interfaces
# set interfaces reth0.0 family inet address <ip address/mask>
# set security zones security-zone <zone> interfaces reth0.0


For example:

On device A:
{primary:node0} 
# set chassis cluster reth-count 2
# set interfaces fe-0/0/2 fastether-options redundant-parent reth1    -for first interface in the group (on Device A)
# set interfaces fe-1/0/2 fastether-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 family inet address 1.2.0.233/24
# set interfaces fe-0/0/0 fastether-options redundant-parent reth0    -for first interface in the group (on Device A)
# set interfaces fe-1/0/0 fastether-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 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


  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 routers.


You can check the cluster status with the following commands.

> show chassis cluster status
> show chassis cluster interfaces
> show chassis cluster statistics

Implementation