Switchover Behavior in an MX Series Virtual Chassis

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.

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 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.

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.

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.