Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Chassis Cluster Redundancy Groups

 

A redundancy group (RG) includes and manages a collection of objects on both nodes of a cluster. An RG is primary on one node and backup on the other node at any given time. For more information, see the following topics:

Understanding Chassis Cluster Redundancy Groups

Chassis clustering provides high availability of interfaces and services through redundancy groups and primacy within groups.

A redundancy group is an abstract construct that includes and manages a collection of objects. A redundancy group contains objects on both nodes. A redundancy group is primary on one node and backup on the other at any time. When a redundancy group is said to be primary on a node, its objects on that node are active.

Redundancy groups are independent units of failover. Each redundancy group fails over from one node to the other independent of other redundancy groups. When a redundancy group fails over, all its objects fail over together.

Three things determine the primacy of a redundancy group: the priority configured for the node, the node ID (in case of tied priorities), and the order in which the node comes up. If a lower priority node comes up first, then it will assume the primacy for a redundancy group (and will stay as primary if preempt is not enabled). If preempt is added to a redundancy group configuration, the device with the higher priority in the group can initiate a failover to become master. By default, preemption is disabled. For more information on preemption, see preempt (Chassis Cluster).

A chassis cluster can include many redundancy groups, some of which might be primary on one node and some of which might be primary on the other. Alternatively, all redundancy groups can be primary on a single node. One redundancy group's primacy does not affect another redundancy group's primacy. You can create up to 128 redundancy groups.

The maximum number of redundancy groups is equal to the number of redundant Ethernet interfaces that you configure.

You can configure redundancy groups to suit your deployment. You configure a redundancy group to be primary on one node and backup on the other node. You specify the node on which the group is primary by setting priorities for both nodes within a redundancy group configuration. The node with the higher priority takes precedence, and the redundancy group's objects on it are active.

If a redundancy group is configured so that both nodes have the same priority, the node with the lowest node ID number always takes precedence, and the redundancy group is primary on it. In a two-node cluster, node 0 always takes precedence in a priority tie.

Understanding Chassis Cluster Redundancy Group 0: Routing Engines

When you initialize a device in chassis cluster mode, the system creates a redundancy group referred to as redundancy group 0. Redundancy group 0 manages the primacy and failover between the Routing Engines on each node of the cluster. As is the case for all redundancy groups, redundancy group 0 can be primary on only one node at a time. The node on which redundancy group 0 is primary determines which Routing Engine is active in the cluster. A node is considered the primary node of the cluster if its Routing Engine is the active one.

The redundancy group 0 configuration specifies the priority for each node. The following priority scheme determines redundancy group 0 primacy. Note that the three-second value is the interval if the default heartbeat-threshold and heartbeat-interval values are used.

  • The node that comes up first (at least three seconds prior to the other node) is the primary node.

  • If both nodes come up at the same time (or within three seconds of each other):

    • The node with the higher configured priority is the primary node.

    • If there is a tie (either because the same value was configured or because default settings were used), the node with the lower node ID (node 0) is the primary node.

The previous priority scheme applies to redundancy groups x (redundancy groups numbered 1 through 128) as well, provided preempt is not configured. (See Example: Configuring Chassis Cluster Redundancy Groups.)

You cannot enable preemption for redundancy group 0. If you want to change the primary node for redundancy group 0, you must do a manual failover.

Caution

Be cautious and judicious in your use of redundancy group 0 manual failovers. A redundancy group 0 failover implies a Routing Engine failover, in which case all processes running on the primary node are killed and then spawned on the new master Routing Engine. This failover could result in loss of state, such as routing state, and degrade performance by introducing system churn.

Understanding Chassis Cluster Redundancy Groups 1 Through 128

You can configure one or more redundancy groups numbered 1 through 128, referred to as redundancy group x. The maximum number of redundancy groups is equal to the number of redundant Ethernet interfaces that you configure (see Maximum Number of Redundant Ethernet Interfaces Allowed (SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, SRX5800, SRX300, SRX320, SRX340, SRX345, SRX 380, SRX550M, and SRX1500)). Each redundancy group x acts as an independent unit of failover and is primary on only one node at a time.

Each redundancy group x contains one or more redundant Ethernet interfaces. A redundant Ethernet interface is a pseudo interface that contains at minimum a pair of physical Gigabit Ethernet interfaces or a pair of Fast Ethernet interfaces. If a redundancy group is active on node 0, then the child links of all the associated redundant Ethernet interfaces on node 0 are active. If the redundancy group fails over to node 1, then the child links of all redundant Ethernet interfaces on node 1 become active.

The following priority scheme determines redundancy group x primacy, provided preempt is not configured. If preempt is configured, the node with the higher priority is the primary node. Note that the three-second value is the interval if the default heartbeat-threshold and heartbeat-interval values are used.

  • The node that comes up first (at least three seconds prior to the other node) is the primary node.

  • If both nodes come up at the same time (or within three seconds of each other):

    • The node with the higher configured priority is the primary node.

    • If there is a tie (either because the same value was configured or because default settings were used), the node with the lower node ID (node 0) is the primary node.

On SRX Series chassis clusters, you can configure multiple redundancy groups to load-share traffic across the cluster. For example, you can configure some redundancy groups x to be primary on one node and some redundancy groups x to be primary on the other node. You can also configure a redundancy group x in a one-to-one relationship with a single redundant Ethernet interface to control which interface traffic flows through.

The traffic for a redundancy group is processed on the node where the redundancy group is active. Because more than one redundancy group can be configured, it is possible that the traffic from some redundancy groups is processed on one node while the traffic for other redundancy groups is processed on the other node (depending on where the redundancy group is active). Multiple redundancy groups make it possible for traffic to arrive over an ingress interface of one redundancy group and over an egress interface that belongs to another redundancy group. In this situation, the ingress and egress interfaces might not be active on the same node. When this happens, the traffic is forwarded over the fabric link to the appropriate node.

When you configure a redundancy group x, you must specify a priority for each node to determine the node on which the redundancy group x is primary. The node with the higher priority is selected as primary. The primacy of a redundancy group x can fail over from one node to the other. When a redundancy group x fails over to the other node, its redundant Ethernet interfaces on that node are active and their interfaces are passing traffic.

Table 1 gives an example of redundancy group x in an SRX Series chassis cluster and indicates the node on which the group is primary. It shows the redundant Ethernet interfaces and their interfaces configured for redundancy group x.

Some devices have both Gigabit Ethernet ports and Fast Ethernet ports.

Table 1: Example of Redundancy Groups in a Chassis Cluster

Group

Primary

Priority

Objects

Interface (Node 0)

Interface (Node 1)

Redundancy group 0

Node 0

Node 0: 254

Routing Engine on node 0

 

Node 1: 2

Routing Engine on node 1

Redundancy group 1

Node 0

Node 0: 254

Redundant Ethernet interface 0

ge-1/0/0

ge-5/0/0

Node 1: 2

Redundant Ethernet interface 1

ge-1/3/0

ge-5/3/0

Redundancy group 2

Node 1

Node 0: 2

Redundant Ethernet interface 2

ge-2/0/0

ge-6/0/0

Node 1: 254

Redundant Ethernet interface 3

ge-2/3/0

ge-6/3/0

Redundancy group 3

Node 0

Node 0: 254

Redundant Ethernet interface 4

ge-3/0/0

ge-7/0/0

Node 1: 2

Redundant Ethernet interface 5

ge-3/3/0

ge-7/3/0

 
 
 

As the example for a chassis cluster in Table 1 shows:

  • The Routing Engine on node 0 is active because redundancy group 0 is primary on node 0. (The Routing Engine on node 1 is passive, serving as backup.)

  • Redundancy group 1 is primary on node 0. Interfaces ge-1/0/0 and ge-1/3/0 belonging to redundant Ethernet interface 0 and redundant Ethernet interface 1 are active and handling traffic.

  • Redundancy group 2 is primary on node 1. Interfaces ge-6/0/0 and ge-6/3/0 belonging to redundant Ethernet interface 2 and redundant Ethernet interface 3 are active and handling traffic.

  • Redundancy group 3 is primary on node 0. Interfaces ge-3/0/0 and ge-3/3/0 belonging to redundant Ethernet interface 4 and redundant Ethernet interface 5 are active and handling traffic.

Example: Configuring Chassis Cluster Redundancy Groups

This example shows how to configure a chassis cluster redundancy group.

Requirements

Before you begin:

  1. Set the chassis cluster node ID and cluster ID. See Example: Setting the Chassis Cluster Node ID and Cluster ID.
  2. Configure the chassis cluster management interface. See Example: Configuring the Chassis Cluster Management Interface.
  3. Configure the chassis cluster fabric. See Example: Configuring the Chassis Cluster Fabric Interfaces.

Overview

A chassis cluster redundancy group is an abstract entity that includes and manages a collection of objects. Each redundancy group acts as an independent unit of failover and is primary on only one node at a time.

In this example, you create two chassis cluster redundancy groups, 0 and 1:

  • 0—Node 0 is assigned a priority of 100, and node 1 is assigned a priority of 1.

  • 1—Node 0 is assigned a priority of 100, and node 1 is assigned a priority of 1.

The preempt option is enabled, and the number of gratuitous ARP requests that an interface can send to notify other network devices of its presence after the redundancy group it belongs to has failed over is 4.

Configuration

CLI Quick Configuration

To quickly configure this 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 from configuration mode.

Step-by-Step Procedure

To configure a chassis cluster redundancy group:

  1. Specify a redundancy group's priority for primacy on each node of the cluster. The higher number takes precedence.
  2. Configure the node with the higher priority to preempt the device with the lower priority and become primary for the redundancy group.

    You cannot enable preemption for redundancy group 0. If you want to change the primary node for redundancy group 0, you must do a manual failover.

  3. Specify the number of gratuitous ARP requests that an interface can send to notify other network devices of its presence after the redundancy group it belongs to has failed over.

Results

From configuration mode, confirm your configuration by entering the show chassis cluster status redundancy-group commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Chassis Cluster Redundancy Group Status

Purpose

Verify the status of a chassis cluster redundancy group.

Action

From operational mode, enter the show chassis cluster status redundancy-group command.

{primary:node0}
user@host>show chassis cluster status redundancy-group 1