Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Chassis Cluster Redundancy Groups

This topic explains that a redundancy group (RG) includes and manages a collection of objects on both nodes of a cluster. At any given time, an RG is primary on one node and acts as a backup on the other node.

Use Feature Explorer to confirm platform and release support for specific features.

Understand Redundancy Groups

A Chassis cluster provides interfaces and services through redundancy groups. Each redundancy group operates with one node in the primary role and the peer node in the backup role.

A redundancy group is a logical construct that manages a collection of related objects across both nodes in a cluster. At any time, a redundancy group is primary on one node and acts as a backup on the other. When a redundancy group is primary on a node, all associated objects on that node are active.

Redundancy groups operate as independent failover units. Each redundancy group can fail over between nodes independently of other redundancy groups. When a redundancy group fails over, all objects associated with that group fail over together.

The primary node for a redundancy group is determined by the following factors, evaluated in order:

  1. The configured priority for each node

  2. The node ID, if priorities are equal

  3. The node startup order

If a node with lower priority comes online first, it assumes primary for the redundancy group and remains primary unless preemption is enabled.

When preemption is configured for a redundancy group, the node with the higher priority can initiate a failover to assume the primary role. By default, preemption is disabled.

A chassis cluster can include multiple redundancy groups. Some redundancy groups can be of which may be primary on one node while others are primary on the peer node. Alternatively, all redundancy groups can be primary on a single node. The primary of one redundancy group does not affect the primary status of any other redundancy group. You can configure up to 128 redundancy groups.

The maximum number of redundancy groups that can be configured is limited to the number of redundant Ethernet interfaces .

Configure redundancy groups based on deployment requirements. For each redundancy group:

  • One node is configured as primary and the other as backup.

  • You assign priorities to both nodes within the redundancy group configuration.

  • The node with the higher priority becomes primary, and the redundancy group’s objects on that node become active.

If both nodes are configured with the same priority, the node with the lower node ID takes precedence. In a two-node cluster, node 0 always takes precedence when priorities are equal.

Understanding Chassis Cluster Redundancy Group 0: Routing Engines

When you initialize a device in chassis cluster mode, the system creates a redundancy group 0 (RG0). RG0 manages the primary and failover of the Routing Engines between the cluster nodes. As with all redundancy groups, RG0 can be primary on only one node at a time.

The node on which RG0 is primary determines which Routing Engine is active in the cluster. A node is considered the primary node of the cluster when its Routing Engine is active .

The RG0 configuration includes a priority value for each node. The following priority scheme is used to determine RG0 primary. Note that the three-second interval applies when the default heartbeat-threshold and heartbeat-interval values are used.

  • If one node comes online at least three seconds before the peer node, that node becomes the primary node.

  • If both nodes come online at the same time, or within three seconds of each other, primary is determines as follows:

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

    • If the priorities are equal (either because the same value is configured or default values are used), the node with the lower node ID becomes the primary node. In a two-node cluster, this is node 0.

The same priority scheme applies to redundancy groups numbered 1 through 128, provided that preemption is not configured.

Preemption cannot be enabled for RG0. To change the primary node for RG0, you must perform a manual failover.

Use RG0 manual failovers with caution. AnRG0 failover triggers a Routing Engine failover, during which all processes running on the current primary node are terminated and then restarted on the new primary Routing Engine. This process can result in loss of state, such as routing information, and may temporarily degrade system performance due to increased system churn.

Understanding Chassis Cluster Redundancy Groups 1 Through 128

You can configure one or more redundancy groups, numbered 1 through 128, collectively referred to as redundancy group x. The maximum number of redundancy groups that can be configured is limited by the number of redundant Ethernet interfaces supported on the device. Each redundancy group x functions 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 consists of at least a pair of physical Gigabit Ethernet interfaces or a pair of Fast Ethernet interfaces. When a redundancy group is active on node 0, the child links of all associated redundant Ethernet interfaces on node 0 are active. When the redundancy group fails over to node 1, the child links of the associated redundant Ethernet interfaces on node 1 become active and begin forwarding traffic.

The following priority scheme determines primary for redundancy group x when preemption is not configured. If preemption is configured, the node with the higher priority becomes the primary node. Note that the three-second interval applies when the default heartbeat-threshold and heartbeat-interval values are used.

  • If the node comes online at least three seconds before the peer node, that node becomes the primary node.

  • If both nodes come online at the same time, or within three seconds of each other:

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

    • If the priorities are equal (either because the same value is configured or default values are used), the node with the lower node IDbecomes the primary node. In a two-node cluster, this is node 0.

In a chassis cluster, you can configure multiple redundancy groups to load-share traffic across the cluster nodes. For example,

  • Some redundancy groups can be primary on one node, while others are primary on the peer node.

  • A redundancy group x can also be configured in a one-to-one relationship with a single redundant Ethernet interface to control the traffic path.

Traffic associated with redundancy group is processed on the node where that redundancy group is active. Because multiple redundancy groups can be configured, traffic for different redundancy groups can be processed on different nodes, depending on where each redundancy group is primary. With multiple redundancy groups, traffic can arrive on an ingress interface that belongs to one redundancy group and exit through an egress interface that belongs to another redundancy group. In some scenarios, traffic can enter the cluster through an ingress interface that belongs to one redundancy group and exit through an egress interface that belongs to another redundancy group. In this case, the ingress and egress interfaces might not be active on the same node. When this occurs, traffic is forwarded across the fabric link to the appropriate node for processing or forwarding.

When you configure a redundancy group x, you must assign a priority to each node. The node with the higher priority is selected as the primary node for that redundancy group. The primary of a redundancy group x can fail over from one node to the other. When a redundancy group x fails over, the redundant Ethernet interfaces on the new primary node become active and begin forwarding traffic.

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

Some devices include both Gigabit Ethernet 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 and serves as the backup.

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

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

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

Example: Configure Chassis Cluster Redundancy Groups

This example explains 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

Procedure

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.