Unified ISSU in a Virtual Chassis

Benefits of Performing a Unified ISSU in an Virtual Chassis

Performing a unified ISSU in an MX Series Virtual Chassis provides the following benefits:

• Upgrades the Junos OS software package while maintaining subscriber sessions.

• Reduces risk associated with a software upgrade. After performing a unified ISSU, the resulting system is exactly the same as if you had upgraded it with a system reboot.

• Prevents software upgrades from negatively affecting the service provider’s ability to fulfill strict service-level agreements (SLAs).

• Eliminates network downtime during software image upgrades.

• Enables faster implementation of new Junos OS features.

• Provides feature parity with unified ISSU support on standalone MX Series routers.

Prerequisites for Performing a Unified ISSU in a Virtual Chassis

Before you start a unified ISSU in a two-member MX Series Virtual Chassis, make sure you do all of the following:

• Ensure that all four Routing Engines in the Virtual Chassis (both Routing Engines in the primary router and both Routing Engines in the backup router) are running the same Junos OS software release.

• Back up the existing router configuration so you can revert (roll back) to it if necessary.

• Verify that both graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) are enabled.

How Unified ISSU Works in a Virtual Chassis

To perform a unified ISSU in an MX Series Virtual Chassis, you issue the request system software in-service-upgrade package-name command from the console window for the primary Routing Engine in the Virtual Chassis primary router (VC-Pp). Issuing this command from the VC-Pp copies the software package to all other Routing Engines in the Virtual Chassis.

The request system software in-service-upgrade package-name command functions the same for upgrading member routers in a Virtual Chassis configuration as it does for upgrading a standalone MX Series router with dual Routing Engines, with the following exceptions:

• The no-copy, no-old-master-upgrade, and unlink options for the request system software in-service-upgrade command are not available for an MX Series Virtual Chassis.

• The reboot option for the request system software in-service-upgrade command is accepted but ignored for an MX Series Virtual Chassis. A unified ISSU always reboots all Routing Engines in the Virtual Chassis member routers.

At a high level, the software performs the following actions after you issue the request system software in-service-upgrade package-name command to upgrade to a new Junos OS software release in a two-member Virtual Chassis configuration:

1. Arms the new Junos OS software release on all Routing Engines in the Virtual Chassis.

   The Routing Engines are still running the old Junos OS software release.

2. Upgrades both standby (backup) Routing Engines (VC-Ps and VC-Bs) in the Virtual Chassis.

   The Virtual Chassis is still actively forwarding traffic.

3. Performs a local switchover of the Routing Engines in the Virtual Chassis backup router (VC-B).

   The local switchover causes the VC-Bs upgraded in Step 2 to become the VC-Bp, and the VC-Bp that was still running the old Junos OS software to become the VC-Bs. The VC-Bp is now running the new Junos OS software release, and the VC-Bs is still running the old Junos OS software release. The Virtual Chassis is still actively forwarding traffic.

4. Upgrades the Packet Forwarding Engines to the new Junos OS software release.

   The Packet Forwarding Engines are now using the upgraded VC-Bp as the Virtual Chassis protocol primary.

5. Performs a local switchover of the Routing Engines in the Virtual Chassis primary router (VC-P).

   The local switchover of the VC-P also causes a global switchover in the Virtual Chassis, which causes the VC-P to become the VC-B. As a result, the VC-Pp becomes the VC-Bs, and the VC-Ps becomes the VC-Bp. The global switchover on the VC-B causes the VC-Bp to become the VC-Pp, and the VC-Bs to become the VC-Ps.

   The VC-Pp and VC-Bp are now running the new Junos OS software release. The VC-Ps (originally the VC-Bp) and VC-Bs (originally the VC-Pp) are still running the old Junos OS software release.

6. Upgrades the standby Routing Engines in the Virtual Chassis (VC-Ps and VC-Bs).

   The Virtual Chassis is now fully upgraded to the new Junos OS software release.

Virtual Chassis Role Transitions After a Unified ISSU

A unified ISSU in an MX Series Virtual Chassis upgrades all Routing Engines in the Virtual Chassis to the new Junos OS software release. In a two-member Virtual Chassis, this includes four Routing Engines: the primary and standby (backup) Routing Engines in the Virtual Chassis primary router, and the primary and standby Routing Engines in the Virtual Chassis backup router. As a result, the member routers and their associated Routing Engines undergo both global and local role transitions after the unified ISSU completes.

A global role transition changes the primary role in the Virtual Chassis by switching the global roles of the Virtual Chassis primary router (VC-P) and Virtual Chassis backup router (VC-B), and applies globally across the entire Virtual Chassis. A local role transition toggles the local primary and backup roles (master and standby, or m and s) of each of the two Routing Engines in a member router, and applies locally only to that member router.

A unified ISSU in an MX Series Virtual Chassis causes the global and local role transitions listed in Table 1.