Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding Nonstop Software Upgrade on EX Series Switches

 

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

This topic covers:

Requirements for Performing an NSSU

The following requirements apply to all switches and Virtual Chassis:

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

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 master and backup must be adjacent to each other in the ring topology. Adjacency permits the master 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 master and backup must maintain their master and backup roles (although mastership 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 these switches and Virtual Chassis:

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

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

  1. The Virtual Chassis master 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 master installs the new software image on the backup and reboots it.
  3. The master resynchronizes the backup.
  4. The master installs the new software image on member switches that are in the linecard role and reboots them, one at a time. The master 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 master performs a graceful Routing Engine switchover, and the upgraded backup becomes the master.
  6. The software on the original master is upgraded and the original master is automatically rebooted. After the original master 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 master 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 master.
  7. The switch installs the new software on the original master Routing Engine.

    To complete the upgrade process, the original master 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 master has been rebooted, you can optionally return control to it by requesting a graceful Routing Engine switchover.

  8. (EX6200 switch only) The original master 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 master Routing Engine. You can reboot the original master 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 master 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 master 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 master Routing Engine.

EX8200 Virtual Chassis

When you request an NSSU on an EX8200 Virtual Chassis:

  1. The master 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 master 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 master external Routing Engine.
  4. The master 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 master Routing Engines, both external and internal.
  8. The member switches perform a graceful Routing Engine switchover, so that the upgraded backup Routing Engines become masters.
  9. The master external Routing Engine performs a graceful Routing Engine switchover so that the backup external Routing Engine is now the master.

To complete the upgrade process, the original master 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 master 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

EX4200 Virtual Chassis

12.1 or later

EX4300 Virtual Chassis

13.2X51-D20 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

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.

Release History Table
Release
Description
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.