Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understanding Nonstop Software Upgrade on EX Series Switches

SUMMARY Nonstop software upgrade (NSSU) is a feature that enables the upgrade of all supported EX Series switches in a network with a single command.

Nonstop software upgrade (NSSU) enables you to upgrade the software running on Juniper Networks EX Series Ethernet Switches with redundant Routing Engines and all member switches in EX Series Virtual Chassis using a single command. During the upgrade there might be minimal network traffic disruption during primary-role switchover, and the extent of disruption could be dependent on the network topology, configuration, network traffic, and other environment factors .

Note:

When an EX Series switch in a mixed Virtual Chassis is upgraded 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.

The following EX Series Virtual Chassis support NSSU:

Performing an NSSU provides these benefits:

  • No disruption to the control plane—An NSSU takes advantage of graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) to ensure no disruption to the control plane. During the upgrade process, interface, kernel, and routing protocol information is preserved.

  • Minimal disruption to network traffic—An NSSU minimizes network traffic disruption by:

    • Upgrading line cards one at a time in an EX6200 switch, EX8200 switch, or EX8200 Virtual Chassis while permitting traffic to continue to flow through the line cards that are not being upgraded.

    • Upgrading member switches one at a time in other EX Series Virtual Chassis while permitting traffic to continue to flow through the members that are not being upgraded.

    To achieve minimal disruption to traffic, you must configure link aggregation groups (LAGs) such that the member links of each LAG reside on different line cards or Virtual Chassis members. When one member link of a LAG is down, the remaining links are up, and traffic continues to flow through the LAG.

Note:

Because NSSU upgrades the software on each line card or on each Virtual Chassis member one at a time, an upgrade using NSSU can take longer than an upgrade using the request system software add command.

In releases prior to Junos OS Release 16.1, for EX6200 switches, EX8200 switches, and EX8200 Virtual Chassis, you can reduce the amount of time an upgrade takes by configuring line-card upgrade groups. The line cards in an upgrade group are upgraded simultaneously, reducing the amount of time it takes to complete an upgrade. See Configuring Line-Card Upgrade Groups for Nonstop Software Upgrade.

Requirements for Performing an NSSU

The following requirements apply to all switches and Virtual Chassis:

Note:

NSSU can only upgrade up to three major releases ahead of the current release on a device. To upgrade to a release more than three releases ahead of the current release on a device, use the NSSU process to upgrade the switch to one or more intermediate releases until the switch is within three major releases of the target release.

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

  • Graceful Routing Engine switchover (GRES) must be enabled.

  • Nonstop active routing (NSR) must be enabled.

    Note:

    Although nonstop bridging (NSB) does not have to be enabled to perform an NSSU, we recommend enabling NSB before performing an NSSU. Enabling NSB ensures that all NSB-supported Layer 2 protocols operate seamlessly during the Routing Engine switchover that is part of the NSSU. In releases prior to Junos OS Release 16.1, see Configuring Nonstop Bridging on Switches (CLI Procedure).

  • For minimal traffic disruption, you must define link aggregation groups (LAGs) such that the member links reside on different Virtual Chassis members or on different line cards.

    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.

The following are requirements for performing NSSU on an EX Series Virtual Chassis (excluding EX6200 or EX8200 Virtual Chassis):

  • The Virtual Chassis members 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 Virtual Chassis primary and backup must be adjacent to each other in the ring topology. Adjacency permits the primary and backup to always be in sync, even when the switches in linecard roles are rebooting.

  • The Virtual Chassis must be preprovisioned so that the linecard role has been explicitly assigned to member switches acting in a linecard role. During an NSSU, the Virtual Chassis members must maintain their roles—the primary and backup must maintain their primary and backup roles (although primary role will change), 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 does not split when an NSSU upgrades a member.

Note:

For the EX4300 Virtual Chassis, you should enable the vcp-no-hold-time statement at the [edit virtual-chassis] hierarchy level before performing a software upgrade using NSSU. If you do not enable the vcp-no-hold-time statement, the Virtual Chassis might split during the upgrade. A split Virtual Chassis can cause disruptions to your network, and you might have to manually reconfigure your Virtual Chassis after the NSSU if the split and merge feature was disabled. For more information about a split Virtual Chassis, see Understanding Split and Merge in a Virtual Chassis

How an NSSU Works

This section describes what happens when you request an NSSU on EX Series switches and Virtual Chassis.

Note:

An EX4650 Virtual Chassis operates the same as a QFX5120 Virtual Chassis, so for details on upgrading an EX4650 Virtual Chassis using NSSU, see Understanding Nonstop Software Upgrade on a Virtual Chassis and Mixed Virtual Chassis and Upgrading Software on a Virtual Chassis and Mixed Virtual Chassis Using Nonstop Software Upgrade instead of this topic.

EX3300, EX3400, EX4200, EX4300, EX4400, EX4500, EX4600, and Mixed Virtual Chassis

When you request an NSSU on an EX3300, EX3400, EX4200, EX4300, EX4400, EX4500, or mixed Virtual Chassis:

  1. The Virtual Chassis primary verifies that:

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

    • Graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) are enabled.

    • The Virtual Chassis has a preprovisioned configuration.

  2. The primary installs the new software image on the backup and reboots it.

  3. The primary resynchronizes the backup.

  4. The primary installs the new software image on member switches that are in the linecard role and reboots them, one at a time. The primary waits for each member to become online and active before starting the software upgrade on the next member.

  5. When all members that are in the linecard role have been upgraded, the primary performs a graceful Routing Engine switchover, and the upgraded backup becomes the primary.

  6. The software on the original primary is upgraded and the original primary is automatically rebooted. After the original primary has rejoined the Virtual Chassis, you can optionally return control to it by requesting a graceful Routing Engine switchover.

EX6200 and EX8200 Switches

When you request an NSSU on a standalone switch with redundant Routing Engines:

  1. The switch verifies that:

    • Both Routing Engines are online and running the same software version.

    • Both Routing Engines have sufficient storage space for the new software image.

    • Graceful Routing Engine switchover and nonstop active routing are enabled.

  2. The switch installs the new software image on the backup Routing Engine and reboots it.

  3. The switch resynchronizes the backup Routing Engine to the primary Routing Engine.

  4. The line cards in the first upgrade group (or the line card in slot 0, if no upgrade groups are defined) download the new image and then restart. Traffic continues to flow through the line cards in the other upgrade groups during this process.

  5. When line cards restarted in Step 4 are online again, the line cards in the next upgrade group download the new image and restart. This process continues until all online line cards have restarted with the new software.

    Note:

    If you have taken a line card offline with the CLI before you start the NSSU, the line card is not restarted and remains offline.

  6. The switch performs a graceful Routing Engine switchover, so that the upgraded backup Routing Engine becomes the primary.

  7. The switch installs the new software on the original primary Routing Engine.

    To complete the upgrade process, the original primary Routing Engine must be rebooted. You can do so manually or have the switch perform an automatic reboot by including the reboot option when you request the NSSU. After the original primary has been rebooted, you can optionally return control to it by requesting a graceful Routing Engine switchover.

  8. (EX6200 switch only) The original primary Routing Engine reboots to complete the software upgrade.

    Note:

    To complete the upgrade process on an EX8200 switch, you must intervene to reboot the original primary Routing Engine. You can reboot the original primary Routing Engine manually or have the switch perform an automatic reboot by including the reboot option when you request the NSSU.

  9. (Optional) After the original primary has been rebooted, you can return control to it by requesting a graceful Routing Engine switchover.

    The switch can maintain normal operations with either Routing Engine acting as the primary Routing Engine after the software upgrade, so you only have to perform this switchover if you want to return Routing Engine control to the original primary Routing Engine.

EX8200 Virtual Chassis

When you request an NSSU on an EX8200 Virtual Chassis:

  1. The primary external Routing Engine verifies that:

    • It has a backup external Routing Engine that is online.

    • All Virtual Chassis members have redundant Routing Engines and the Routing Engines are online.

    • All Routing Engines are running the same software version.

    • All Routing Engines have sufficient storage space for the new software image.

    • Graceful Routing Engine switchover and nonstop active routing (NSR) are enabled.

  2. The primary external Routing Engine installs the new software image on the backup external Routing Engine and reboots it.

  3. The backup external Routing Engine resynchronizes with the primary external Routing Engine.

  4. The primary external Routing Engine installs the new software on the backup Routing Engines in the member switches and reboots the backup Routing Engines.

  5. When the reboot of the backup Routing Engines complete, the line cards in the first upgrade group download the new image and then restart. (If no upgrade groups are defined, the line card in slot 0 of member 0 downloads the new image and restarts.) Traffic continues to flow through the line cards in the other upgrade groups during this process.

  6. When line cards restarted in Step 5 are online again, the line cards in the next upgrade group (or the next sequential line card) download the new image and restart. This process continues until all online line cards have restarted with the new software.

    Note:

    If you have taken a line card offline with the CLI before you start the NSSU, the line card is not restarted and remains offline.

  7. The new software image is installed on the primary Routing Engines, both external and internal.

  8. The member switches perform a graceful Routing Engine switchover, so that the upgraded backup Routing Engines become primaries.

  9. The primary external Routing Engine performs a graceful Routing Engine switchover so that the backup external Routing Engine is now the primary.

To complete the upgrade process, the original primary Routing Engines, both external and internal, must be rebooted. You can do so manually by establishing a console connection to each Routing Engine or have the reboot performed automatically by including the reboot option when you request the NSSU. After the original primary external Routing Engine has been rebooted, you can optionally return control to it by requesting a graceful Routing Engine switchover.

NSSU Limitations

You cannot use an 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 cannot 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 do so by rebooting 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

A Virtual Chassis must be running a Junos OS release that supports NSSU before you can perform an NSSU. If a Virtual Chassis is running a software version that does not support NSSU, use the request system software add command.

Table 1 lists the EX Series switches and Virtual Chassis that support NSSU and the Junos OS release at which they began supporting it.

Table 1: Platform and Release Support for NSSU

Platform

Junos OS Release

EX3300 Virtual Chassis

12.2 or later

EX3400 Virtual Chassis

15.1X53-D55 or later

EX4100 and EX4100-F switches

22.2 or later

EX4100 Multigigabit switches

22.2 or later

EX4200 Virtual Chassis

12.1 or later

EX4300 Virtual Chassis

13.2X51-D20 or later
EX4300 Multigigabit Virtual Chassis 18.2R1 or later
EX4400 Virtual Chassis 21.1 or later
EX4400 Multigigabit Virtual Chassis 21.2 or later

EX4500 Virtual Chassis

12.1 or later

EX4550 Virtual Chassis

12.2 or later

Mixed EX4200 and EX4500 Virtual Chassis

12.1 or later

Mixed EX4200 and EX4550 Virtual Chassis

12.2 or later

Mixed EX4200, EX4500, and EX4550 Virtual Chassis

12.2 or later

Mixed EX4500 and EX4550 Virtual Chassis

12.2 or later
Mixed EX4300 and EX4600 Virtual Chassis 13.2X51-D25 or later

EX6200 switch

12.2 or later

EX8200 switch

10.4 or later

EX8200 Virtual Chassis

11.1 or later

Overview of NSSU Configuration and Operation

You must ensure that the configuration of the switch or Virtual Chassis meets the requirements described in Requirements for Performing an NSSU. NSSU requires no additional configuration.

In releases prior to Junos OS Release 16.1, for EX6200 switches, EX8200 switches, and EX8200 Virtual Chassis, you can optionally configure line-card upgrade groups using the CLI. See Example: Configuring Line-Card Upgrade Groups for Nonstop Software Upgrade on EX Series Switches.

You perform an NSSU by executing the request system software nonstop-upgrade command. For detailed instructions on how to perform an NSSU, see the topics in Related Documentation.

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
16.1
In releases prior to Junos OS Release 16.1, for EX6200 switches, EX8200 switches, and EX8200 Virtual Chassis, you can reduce the amount of time an upgrade takes by configuring line-card upgrade groups.