Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Switchover Behavior in an MX Series Virtual Chassis

When an active or primary hardware or software component fails or is temporarily shut down, you can manually initiate a switchover to a backup component that takes over the functions of the unavailable primary component. You can initiate two types of switchovers in a Virtual Chassis configuration for MX Series 5G Universal Routing Platforms:

  • Global switchover—Changes the primary role in an MX Series Virtual Chassis by switching the global roles of the primary router and backup router in the Virtual Chassis configuration.

  • Local switchover—Toggles the local primary role of the dual Routing Engines in a member router of the Virtual Chassis.

During a switchover, the roles assigned to the member routers and Routing Engines in a Virtual Chassis configuration change. This topic describes the role transitions that occur so you can better understand how an MX Series Virtual Chassis behaves during a global or local switchover. The topic also describes how you can determine whether the member routers are ready for a global graceful Routing Engine switchover (GRES) operation from a database synchronization perspective.

Virtual Chassis Role Transitions During a Global Switchover

To change the primary role in an MX Series Virtual Chassis and cause a global switchover, you issue the request virtual-chassis routing-engine master switch command from the primary Routing Engine in the Virtual Chassis primary router (VC-Pp).

After you issue the request virtual-chassis routing-engine master switch command, the current Virtual Chassis primary router (VC-P) and the current Virtual Chassis backup router (VC-B) switch roles. The former VC-P becomes the new VC-B, and the former VC-B becomes the new VC-P. After the VC-P and VC-B switch roles, the primary Routing Engine on the new VC-B (VC-Bp) reboots, causing the role transitions listed in Table 1.

Table 1: Virtual Chassis Role Transitions During Global Switchover

Virtual Chassis Role Before Global Switchover

Virtual Chassis Role After Global Switchover

Virtual Chassis primary router (VC-P)

Virtual Chassis backup router (VC-B)

Virtual Chassis backup router (VC-B)

Virtual Chassis primary router (VC-P)

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

The local roles (master and standby, or m and s) of the Routing Engines in the Virtual Chassis primary router change after a global switchover, but the local roles of the Routing Engines in the Virtual Chassis backup router do not change. For example, as shown in Table 1, the primary Routing Engine in the Virtual Chassis primary router (VC-Pp) becomes the standby Routing Engine in the Virtual Chassis backup router (VC-Bs) after the global switchover. By contrast, the primary Routing Engine in the Virtual Chassis backup router (VC-Bp) remains the primary Routing Engine in the Virtual Chassis primary router (VC-Pp) after the global switchover.

Virtual Chassis Role Transitions During a Local Switchover

To ensure redundancy in a two-member Virtual Chassis configuration, each of the two member routers must be configured with dual Routing Engines. To toggle local primary role between the primary Routing Engine and the standby Routing Engine in the member router, you issue the request chassis routing-engine master switch command from either the primary Routing Engine in the Virtual Chassis primary router (VC-Pp) or from the primary Routing Engine in the Virtual Chassis backup router (VC-Bp).

Table 2 shows the role transitions caused by a local switchover when you issue the request chassis routing-engine master switch command from the VC-Pp.

Table 2: Virtual Chassis Role Transitions During Local Switchover Performed from VC-Pp

Virtual Chassis Role Before Local Switchover

Virtual Chassis Role After Local Switchover

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

Table 3 shows the role transitions caused by a local switchover when you issue the request chassis routing-engine master switch command from the VC-Bp.

Table 3: Virtual Chassis Role Transitions During Local Switchover Performed from VC-Bp

Virtual Chassis Role Before Local Switchover

Virtual Chassis Role After Local Switchover

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Standby Routing Engine in the Virtual Chassis backup router (VC-Bs)

Primary Routing Engine in the Virtual Chassis backup router (VC-Bp)

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Primary Routing Engine in the Virtual Chassis primary router (VC-Pp)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

Standby Routing Engine in the Virtual Chassis primary router (VC-Ps)

When you perform a local switchover, the primary (m) and standby (s) local roles of the Routing Engines in each member router change only in the member router from which you issue the request chassis routing-engine master switch command. For example, when you issue a local switchover from the VC-Pp, as shown in Table 2, the local roles change on the VC-P but remain the same on the VC-B. Conversely, when you issue a local switchover from the VC-Bp, as shown in Table 3, the local roles change on the VC-B but remain the same on the VC-P.

A local switchover performed from the VC-Pp also changes the global roles of the member routers, as shown in Table 2. By contrast, a local switchover performed from the VC-Bp changes only the local roles of the Routing Engines, as shown in Table 3.

Virtual Chassis Role Transitions During Virtual Chassis Formation

In the rare case when the virtual chassis has "split" (that is, lost connectivity), each member may take the Virtual Chassis primary router (VC-P) role, resulting in two VC-P chassis. When Virtual Chassis connectivity is restored, an election process assigns the Virtual Chassis primary (VC-P) role to one member and the Virtual Chassis backup (VC-B) role to the other member. As of Junos OS Release 15.1, in the same manner as the global GRES behavior, the newly elected VC-B member causes its local primary Routing Engine to reboot after passing local primary role to its local standby Routing Engine. This is an intentional action which allows the VC-B chassis to become GRES-ready more quickly.

Note:

Rebooting both Routing Engines in the VC-P or VC-B chassis, or just the primary Routing Engine in either the VC-P or VC-B chassis, may not result in a graceful switchover, and is not recommended.

GRES Readiness in a Virtual Chassis Configuration

Depending on the configuration, a variable amount of time is required before a router is ready to perform a graceful Routing Engine switchover (GRES). Attempting a GRES operation before the router is ready can cause system errors and unexpected behavior. To determine whether the member routers in an MX Series Virtual Chassis configuration are ready for a GRES operation from a database synchronization perspective, you can issue the request virtual-chassis routing-engine master switch check command from the Virtual Chassis primary router (VC-Pp) before you initiate the GRES operation.

The request virtual-chassis routing-engine master switch check command checks various system and database components on the member routers to determine whether they are ready for GRES, but does not initiate the global GRES operation itself. The readiness check includes ensuring that a system timer, which expires after 300 seconds, completes before the global GRES operation begins.

Using the request virtual-chassis routing-engine master switch check command before you initiate the GRES operation ensures that the subscriber management and kernel databases on both member routers in an MX Series or Virtual Chassis are synchronized and ready for the GRES operation.