Juniper SRX High Availability (HA) & clustering: Part 2

In Juniper SRX High Availability (HA) & clustering: Part 1 I discussed the theory of the key terms and concepts used in configuring reth groups, fab links and clustering in general. In this part we actually dive deep into the actual configuration.

The broad steps that will be covered in this part:

1) Setting up control links
2) Setting up fab links
3) Creating a redundancy group
4) Configuring reth interfaces
5) Enabling clustering

Pre-config steps:

1) Make sure both SRX have the same junos.
2) Both have the same additional licenses configured

Control links

In SRX 550 and SRX 650 there can be only one control link. All the control plane data is synced over this link. In the aforementioned models ge-0/0/1 of the two SRX's have to be connected with each other.

When we enable clustering, the ge-0/0/1 of the secondary SRX will automatically reconfigure itself as ge-9/0/1, This is a hardcoded value and cannot be modified.

Fab links

To configure fab links, connect ge-0/0/2 of both the SRX. You can use any port except ge-0/0/0 and ge-0/0/1.

Remember that we have not enabled clustering yet. To do that run the following commands:

On SRX A: >set chassis cluster cluster-id 1 node 0 reboot 
On SRX B: >set chassis cluster cluster-id 1 node 1 reboot

Note: 1) This has to be run in operational mode and not in configure mode.
2) You cannot assign 0 as cluster-id. The range is 1 to 15

This will enable clustering and ge-0/0/0 will become fxp0 on both the SRX. This will be used for management traffic of both the SRX.

ge-0/0/1 of both SRX will become fxp1

All the interfaces in SRX - secondary will become ge-9/0/<> (in SRX 550 and 650)

If clustering has been successful running show chassis cluster status will display redundancy group 0 information.

At this moment it is important to understand the special role of redundancy group 0.

Redundancy group 0

You can define any number of redundancy groups. Each group has the SRX's with one acting as master and the other as backup. All the properties and objects associated with a redundancy group point to one master and one backup.

For example I can map a couple of interfaces with redundancy group 1 and specify SRX B as master. For a couple of other interfaces i can specify redundancy group 2 with SRX A as the master.

Redundancy group 0 has the routing engine. The active SRX in this redundancy group determines which SRX has an active routing engine.

As soon as you enable clustering the redundancy group 0 becomes active and need not be configured. ( you can set the priority which will be discussed later)

Setting up fab links

Fabric links are responsible for carrying the transit traffic. For example, if an uplink from an SRX goes down it will seamlessly start sending traffic to the other SRX using this link.

It is advised to connect ge-0/0/2--> ge-9/0/2 and ge-0/0/3 --> ge-9/0/3.

Yes, fab links can be bundled. Post configuration, one link acts to send internal messages while the other is used purely to send transit traffic.

set interfaces fab0 fabric-options member-interfaces ge-0/0/2 
set interfaces fab0 fabric-options member-interfaces ge-0/0/3
set interfaces fab1 fabric-options member-interfaces ge-9/0/2 
set interfaces fab1 fabric-options member-interfaces ge-9/0/3

NOTE: fab0 will have one/two interfaces on SRX A and fab1 will have corresponding interfaces in SRX B. Unlike aggregation where an ae0 will have interfaces from two switches.

set chassis cluster redundancy-group 0 node 0 priority 100 
set chassis cluster redundancy-group 0 node 1 priority 1

Creating a redundancy group and reth interfaces

You can assign interfaces to a particular redundancy group. In this simple scenario, we will configure the downlinks to SRX as reth0 with redundancy group 1 and reth0 in redundancy group 1.

We can put both the reth interface in the same group if we want to.We will configure so that SRX A will have primary link as its downlink while SRX B will be the primary for reth1.

set chassis cluster redundancy-group 2 node 0 priority 100 
set chassis cluster redundancy-group 2 node 1 priority 1
set chassis cluster reth-count 2
set interfaces ge-2/0/1 gigether-options redundant-parent reth0  //assigning a physical port to reth0
set interfaces ge-11/0/1 gigether-options redundant-parent reth0 //assigning a similar port in SRX B to reth0
set interfaces ge-2/0/2 gigether-options redundant-parent reth1 
set interfaces ge-11/0/2 gigether-options redundant-parent reth1
set interfaces reth0 redundant-ether-options redundancy-group 0 //mapping reth0 to redundancy group 1
set interfaces reth1 redundant-ether-options redundancy-group 1 //mapping reth1 to redundancy group 1
set security zones security-zone trust interfaces reth0.0
set security zones security-zone untrust interfaces reth1.0

We have basically configure redundancy group 0 node 0 (ie SRX A) to be primary (higher priority leads), while for redundancy group 1 node 1 (SRX B) acts as primary.

Commit your changes and clustering is enabled

Traffic analysis

All the traffic from internal network will hit SRX A since it is the primary interface for downlink. To go out it will pass through fab link, to SRX B and exit from it. This is because we have configured SRX B to be the primary for the outbound link.

Our model SRX architecture

This is just a simple configuration and complexities can arise when the topology becomes complex. Moreover interesting features like link monitoring have not been discussed. This will form part 3 of this series.