Understanding Nonstop Software Upgrade on a Virtual Chassis and Mixed Virtual Chassis

Benefits of NSSU

• No disruption to the control plane—NSSU uses graceful Routing Engine switchover (GRES) (and nonstop active routing (NSR) on applicable platforms) to ensure no disruption occurs to the control plane. During the upgrade process, the Virtual Chassis preserves interface, kernel, and routing protocol information.

• Minimal disruption to network traffic—NSSU minimizes network traffic disruption by upgrading member switches one at a time, enabling the primary and backup members to maintain their primary and backup roles (although primary role will change) without disrupting traffic, and permitting traffic to continue to flow through members in the linecard role that are not being upgraded.

Requirements for Performing an NSSU

Requirements for performing NSSU for a Virtual Chassis include:

• All Virtual Chassis members and all Routing Engines must be running the same Junos OS release.

• You must enable Graceful Routing Engine switchover (GRES).

• You must enable nonstop active routing (NSR) for applicable platforms.

  Although nonstop bridging (NSB) is not required to perform an NSSU, we also recommend enabling NSB before performing an NSSU on applicable platforms. NSB ensures that all NSB-supported Layer 2 protocols operate seamlessly when the Routing Engine switches over during NSSU. See Configuring Nonstop Bridging on Switches (CLI Procedure).

• To minimize traffic disruption, you must configure link aggregation groups (LAGs) such that the member links of each LAG reside on different Virtual Chassis members, and configure Link Aggregation Control Protocol (LACP) to monitor LAG member link states. When one member link of a LAG is down, the remaining links are up, and traffic continues to flow through the LAG. For more information on configuring LAGs and LACP, see Configuring Link Aggregation and Configuring Aggregated Ethernet LACP (CLI Procedure).

  Note:

  When you upgrade an EX Series switch in a mixed Virtual Chassis to Junos OS Release 15.1 or later from a release earlier than Release 15.1, there might be a drop in traffic for up to 60 seconds.

  Note:

  During an NSSU operation, if you try to view LAG interface status on the primary Routing Engine member using the show interfaces ae-ae-interface-number CLI command, you might see incorrect or zero traffic counts. To work around this problem, run the command on the backup Routing Engine member instead if that member is already loaded and running.

Requirements for the Virtual Chassis or mixed Virtual Chassis members being upgraded using NSSU:

• The member switches must be connected in a ring topology so that no member is isolated as a result of another member being rebooted. This topology prevents the Virtual Chassis from splitting during an NSSU.

• The primary and backup member switches must be adjacent to each other in the ring topology. Adjacent placement ensures the primary and backup are always in sync while the member switches in linecard roles are rebooting.

• The Virtual Chassis is preprovisioned and you have explicitly assigned the linecard role to the member switches acting in a linecard role. The Virtual Chassis primary and backup member switches change primary role while one or the other is being upgraded during NSSU, but they must maintain their primary and backup routing engine roles, and the remaining switches must maintain their linecard roles.

• A two-member Virtual Chassis must have no-split-detection configured so that the Virtual Chassis doesn’t split when an NSSU upgrades a member. See Understanding Split and Merge in a Virtual Chassis.

How an NSSU Works on a Virtual Chassis and Mixed Virtual Chassis

When you request an NSSU on a Virtual Chassis or mixed Virtual Chassis:

1. The Virtual Chassis primary verifies that:

   • The backup is online and running the same software version.

   • You enabled Graceful Routing Engine switchover (GRES), and, if applicable, nonstop active routing (NSR).

   • You used a preprovisioned configuration to set up the Virtual Chassis.

2. The primary copies the new software image to the backup and remaining linecard role members in sequence using rcp.

   (For QFX5100 Virtual Chassis only) Starting with Junos OS Release 14.1X53-D40, to optimize the time needed to complete an NSSU operation for a Virtual Chassis, the primary uses parallel rcp sessions to copy the new software to multiple members at a time (rather than waiting for the copy operation to complete to each member before starting to copy the software image to the next member). The primary uses a default algorithm to determine the number of parallel copy operations based on the number of members in the Virtual Chassis, or you can configure a specific number using the rcp-count configuration statement. See rcp-count for details.

   Note:

   If copying the new software to any member fails, NSSU terminates the upgrade process for the entire Virtual Chassis without rebooting any members, and logs the error condition. Starting with Junos OS Release 14.1X53-D40, if an NSSU copy operation to a member fails, the primary performs an additional error recovery measure to remove the new software from the members to which it was already transferred.

3. The primary restarts the backup member switch with the new software, and the backup resynchronizes with the primary.

4. The primary loads and reboots member switches that are in the linecard role, one at a time. The primary waits for each member to become online and active running the new software before rebooting the next member.

   • If you configured upgrade groups, the Virtual Chassis members in the first upgrade group load the new image and restart. When the members in that upgrade group are online again, the members in the next upgrade group load the new image and restart. (NSSU upgrades the groups in the order that they appear in the configuration.)

   • Traffic continues to flow through the other members during this process.

5. Rebooting continues until all active members have restarted with the new software.

   Note:

   If any linecard role member fails to reboot successfully, NSSU terminates the upgrade process and logs the error condition. In this case, to avoid Virtual Chassis instability, you should either back out the partial upgrade by restoring the old software and rebooting the members that were already rebooted with the new software, or try to manually reboot all members with the new software that was copied to them, so all members come online again running the same version of the software.

   Starting with Junos OS Release 14.1X53-D40, NSSU automatically invokes recovery measures if the reboot fails on any linecard role member, stopping the sequential reboot process and bringing down and rebooting the entire Virtual Chassis. The Virtual Chassis then cleanly brings up all members at the same time running the new software, which recovers Virtual Chassis stability more quickly than having an unstable Virtual Chassis running different versions of the software trying to converge.

6. After the primary has upgraded all members in the linecard role, it performs a graceful Routing Engine switchover and the upgraded backup member switch becomes the new primary.

7. The new primary upgrades the software on the original primary and automatically reboots it. After the original primary has rejoined the Virtual Chassis, you can optionally revert primary role to that switch by explicitly requesting another graceful Routing Engine switchover.

NSSU Limitations

You can’t use NSSU to downgrade the software—that is, to install an earlier version of the software than is currently running on the switch. To install an earlier software version, use the request system software add command.

You can’t roll back to the previous software version after you perform an upgrade using NSSU. If you need to roll back to the previous software version, you can reboot from the alternate root partition if you have not already copied the new software version into the alternate root partition.

NSSU and Junos OS Release Support

NSSU works only on some Virtual Chassis with particular from and to Junos OS Releases. Contact Juniper Networks Technical Assistance Center (JTAC) to confirm supported from and to releases if you are considering upgrading your Virtual Chassis using NSSU.

If your Virtual Chassis is running a software version that does not support NSSU or does not support the combination of from and to releases with NSSU, use the request system software add command to upgrade the member switches in the Virtual Chassis individually.

You can also refer to this network configuration example on how to manually upgrade a two-member QFX Series Virtual Chassis with minimal impact to traffic flow when NSSU is not supported:

• Two-Member QFX Series Virtual Chassis Upgrade Procedure

Overview of NSSU Configuration and Operation

For NSSU to succeed, the Virtual Chassis and member switches must meets the requirements in Requirements for Performing an NSSU. NSSU requires only those configuration steps.

If your Virtual Chassis meets the NSSU requirements, simply enter the request system software nonstop-upgrade command to start NSSU. See Upgrading Software on a Virtual Chassis and Mixed Virtual Chassis Using Nonstop Software Upgrade for details.