Redundancy group in juniper srx cluster

In a Juniper SRX Cluster, a Redundancy Group (RG) is a logical construct that is used to group interfaces and other resources that share a common state in the High Availability (HA) configuration. The concept of redundancy groups is central to SRX’s HA clustering because they define how traffic is handled and how failover occurs between the nodes (SRX devices) in the cluster.

Each Redundancy Group is associated with one or more physical interfaces (called Redundant Ethernet interfaces or reth interfaces), and these interfaces carry traffic for a specific redundancy group. When a failover occurs, the active node (master node) in the cluster controls the interfaces associated with that redundancy group, while the backup node (slave node) is in standby mode. If the master node fails, the backup node takes over the interfaces in that redundancy group.

Key Points of a Redundancy Group

1. Redundancy Groups (RGs) are configured to define which interfaces will failover together and how traffic is distributed in case of failure.
2. Each redundancy group can have one or more physical interfaces (referred to as reth interfaces) associated with it.
3. Redundancy Groups help to control which devices handle which traffic in the event of failover.
4. In case of a failure on the active node, the passive node (backup) assumes control of the reth interfaces associated with the failed group, ensuring continuity of traffic.

Redundancy Group Configuration

Each Redundancy Group is assigned a unique ID (from 0 to 15), and these groups are configured under the chassis cluster settings. In practice, redundancy groups provide high availability by controlling failover behaviors at the interface level.

Here is a typical configuration for Redundancy Groups in a Juniper SRX Cluster:

Example Configuration Steps for Redundancy Groups

1. Define the Redundancy Groups

In an HA setup, you define redundancy groups to specify which interfaces will be shared and failover together.

# On both devices
set chassis cluster redundancy-group 0 node 0 priority 100   # Primary node
set chassis cluster redundancy-group 0 node 1 priority 50    # Backup node

• In this example, Redundancy Group 0 is being configured.
• node 0 is the active node with a priority of 100.
• node 1 is the passive node with a priority of 50.

2. Associate Redundant Ethernet Interfaces (reth) with Redundancy Groups

You then map the reth interface to the appropriate redundancy group. Each redundancy group must have one or more reth interfaces associated with it.

# On both devices
set interfaces reth0 redundant-ethernet-group 0
set interfaces reth1 redundant-ethernet-group 1

In this configuration:

• reth0 is assigned to Redundancy Group 0.
• reth1 is assigned to Redundancy Group 1.

3. Assign IP Addresses to Redundant Ethernet Interfaces

You assign IP addresses to the reth interfaces, which will be the virtual IP (VIP) addresses that clients and other systems will connect to.

# On both devices
set interfaces reth0 unit 0 family inet address 192.168.100.1/24  # VIP for redundancy group 0
set interfaces reth1 unit 0 family inet address 192.168.200.1/24  # VIP for redundancy group 1

Here, reth0 is given a virtual IP address of 192.168.100.1/24 for redundancy group 0, and reth1 is assigned a different virtual IP address for redundancy group 1.

4. Enable Redundancy Group Synchronization

For session synchronization and other HA mechanisms, you need to enable synchronization between the nodes for each redundancy group.

# On both devices
set chassis cluster redundancy-group 0 sync

This command ensures that both nodes in the cluster synchronize session states for Redundancy Group 0, allowing seamless failover without dropping connections.

5. Configure Failover Behavior and State

In case of a failure, you can specify the failover behavior for the redundancy group. Typically, the system will use priority to determine which node becomes the master and which becomes the backup. Higher priority values are preferred as the active node.

# On both devices
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 50

Here, node 0 (Device 1) will be the primary node for Redundancy Group 0 because it has a higher priority (100 vs. 50).

6. Verify Redundancy Group Status

Once configured, you can verify the status of redundancy groups using the following command:

# On either device
show chassis cluster redundancy-group

This will display the current state of each redundancy group, such as which node is active (master) and which is passive (backup), and the status of associated interfaces.

Redundancy Group Failover

The failover mechanism in a Juniper SRX HA cluster relies on Redundancy Groups. When a failure occurs (e.g., link failure, node failure, or interface failure), the following happens:

1. The backup node takes over the role of the active node for the affected Redundancy Group.
2. The Virtual IP (VIP) associated with the reth interface in the redundancy group moves to the backup node.
3. Traffic flows through the backup node, and failover should be transparent to clients if session synchronization is properly set up.

For example, if the primary node in Redundancy Group 0 fails, the backup node (with the lower priority) will take over the reth0 interface and the VIP (192.168.100.1).