Understanding Split and Merge in a Virtual Chassis

What Happens When a Virtual Chassis Configuration Splits

When a Virtual Chassis configuration splits into two separate Virtual Chassis configurations, the individual member switches detect this topology change and run the primary-role election algorithm to select a new primary for each of the two Virtual Chassis configurations. The new primaries then determine whether their Virtual Chassis configuration remains active. One of the configurations remains active based on the following:

• It contains both the stable primary and the stable backup (that is, the primary and backup from the original Virtual Chassis configuration before the split).

• It contains the stable primary and the configuration is greater than half the Virtual Chassis size.

• It contains the stable backup and is at least half the Virtual Chassis size.

In accordance with the rules given in the second and third list items, if the Virtual Chassis configuration splits into two equal parts and the stable primary and stable backup are in different parts, then the part that contains the stable backup becomes active.

Note:

The number of members in the Virtual Chassis configuration includes all member switches connected to date minus the number whose Virtual Chassis member IDs have been recycled (that is, made available for reassignment). Therefore, the size of the Virtual Chassis configuration increases when a new member switch is detected and decreases when a member switch's ID is recycled.

These rules ensure that only one of the two separate Virtual Chassis configurations created by the split remains active. The member switches in the inactive Virtual Chassis configuration remain in a linecard role. For the inactive members to become active again, one of the following things must happen:

• The problem that caused the original Virtual Chassis configuration to split is resolved, allowing the two Virtual Chassis configurations to merge.

• You load the factory default configuration on the inactive members, which causes the inactive members to function as standalone switches or become part of a different Virtual Chassis configuration.

Note:

When any member (mostly linecard or backup) goes offline for a prolonged duration, it is strongly recommended to recycle member ID using the request virtual-chassis recycle command for non-provisioned virtual chassis scenarios and the delete virtual-chassis member command for pre-provisioned virtual chassis scenarios. This is strongly recommended to prevent any issues that could result in an unstable virtual chassis.

Merging Virtual Chassis Configurations

There are two scenarios in which separate Virtual Chassis merge:

• A Virtual Chassis configuration that had split into two is now merging back into a single configuration because the problem that had caused it to split has been resolved.

• You want to merge two Virtual Chassis that had not previously been configured together.

Every Virtual Chassis configuration has a unique ID (VCID) that is automatically assigned when the Virtual Chassis configuration is formed. You can also explicitly assign a VCID using the set virtual-chassis id command. A VCID that you assign takes precedence over automatically assigned VCIDs.

When you reconnect the separate Virtual Chassis configurations or connect them for the first time, the members determine whether or not the separate Virtual Chassis configurations can merge. The members use the following rules to determine whether a merge is possible:

• If the Virtual Chassis configurations have the same VCID, then the configurations can merge. If the two Virtual Chassis were formed as the result of a split, they have the same VCID.

• If the VCIDs are different, then the two configurations can merge only if both are active (inactive configurations cannot merge, ensuring that members removed from one Virtual Chassis configuration do not become members of another Virtual Chassis configuration). If the configurations to merge are both active and one of them has a user-configured VCID, this ID becomes the ID of the merged Virtual Chassis. If neither Virtual Chassis has a user-configured VCID, then the VCID of the configuration with the highest primary-role priority becomes the ID of the merged Virtual Chassis. The resulting merged Virtual Chassis configuration is active.

When you connect two Virtual Chassis configurations:

1. Connecting the two split Virtual Chassis configurations triggers the shortest-path-first (SPF) algorithm. The SPF algorithm computes the network topology and then triggers the primary-role election algorithm. The primary-role election algorithm waits for the members to synchronize the topology information before running.

2. The primary-role election algorithm merges the VCIDs of all the members.

3. Each member runs the primary-role election algorithm to select a primary and a backup from among all members with the same VCIDs. For more information, see Understanding How the Primary in a Virtual Chassis Is Elected.

4. The primary determines whether the Virtual Chassis configuration is active or inactive. (See What Happens When a Virtual Chassis Configuration Splits.)

5. If the Virtual Chassis configuration is active, the primary assigns roles to all members. If the Virtual Chassis configuration is inactive, the primary assigns all members the role of linecard.

6. When the other members receive their role from the primary, they change their role to backup or linecard. They also use the active or inactive state information sent by the primary to set their own state to active or inactive and to construct the Virtual Chassis member list from the information sent by the primary.

7. If the Virtual Chassis state is active, the primary waits for messages from the members indicating that they have changed their roles to the assigned roles, and then the primary changes its own role to primary.

Note:

When you merge two Virtual Chassis that had not previously been part of the same Virtual Chassis configuration, any configuration settings (such as the settings for Telnet and FTP services, graceful Routing Engine switchover (GRES), fast failover, VLANs, and so on) that exist on the new primary become the configuration settings for all members of the new Virtual Chassis, overwriting any other configuration settings.