request system software nonstop-upgrade

Syntax

Description

Perform a nonstop software upgrade (NSSU) on a switch with redundant Routing Engines or on a Virtual Chassis or Virtual Chassis Fabric (VCF). The behavior of this command depends on the type of switch, Virtual Chassis, or VCF where you run it, as follows:

• When you run this command on any of the following Virtual Chassis or VCF configurations, NSSU upgrades all members of the Virtual Chassis:

  • EX3300, EX3400, EX4200, EX4300,EX4400, EX4500, EX4550, EX4600, or EX4650-48Y Virtual Chassis

  • Mixed Virtual Chassis composed of any combination of EX4200, EX4500, and EX4550 switches, or EX4300 and EX4600 switches

  • QFX3500 and QFX3600 Virtual Chassis

  • QFX5100 Virtual Chassis

  • QFX5120-48Y, QFX5120-48T or QFX5120-32C Virtual Chassis

  • Fixed configuration of switches in a VCF (QFX3500/QFX3600 and QFX5100 switches)

  • Mixed VCF composed of any combination of QFX3500/QFX3600, QFX5100, and EX4300 switches

  The original Virtual Chassis or VCF backup becomes the primary. The new primary automatically upgrades and reboots the original primary, which then rejoins the Virtual Chassis or VCF as the backup.

• When you run this command on an EX6200 or EX8200 switch, NSSU upgrades both the backup and primary Routing Engines. The original backup Routing Engine becomes the new primary at the end of the upgrade.

  • On an EX6200 switch, NSSU automatically reboots the original primary Routing Engine.

  • On an EX8200 switch, NSSU does not automatically reboot the original primary Routing Engine unless you specify the reboot option.

• When you run this command on an EX8200 Virtual Chassis, NSSU upgrades all primary and backup Routing Engines in the Virtual Chassis, including the external Routing Engines. The original backup Routing Engines become the new primary Routing Engines. NSSU does not automatically reboot the original primary Routing Engines unless you specify the reboot option.

This command has the following requirements:

• All Virtual Chassis members, VCF 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).

  Note:

  Although not required, we recommend you also enable nonstop bridging (NSB). NSB ensures that all NSB-supported Layer 2 protocols operate seamlessly during the Routing Engine switchover during NSSU. See Configuring Nonstop Bridging on EX Series Switches (CLI Procedure).

• You must run the command from the primary Routing Engine on a standalone switch or from the primary on a Virtual Chassis.

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

• For all Virtual Chassis (except EX8200 Virtual Chassis):

  • The Virtual Chassis members must be connected in a ring topology. A ring 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. With adjacent placement, the primary and backup are always in sync while the switches in line-card roles are rebooting.

  • The Virtual Chassis must be preprovisioned so the line-card role is explicitly assigned to member switches acting in a line-card role. During an NSSU, the primary and backup member switches must maintain their Routing Engine roles (although the primary role switches to the backup), and the remaining switches must maintain their line-card roles.

  • In a two-member Virtual Chassis, you must configure no-split-detection so the Virtual Chassis doesn’t split during NSSU.

• For Virtual Chassis Fabric:

  • You can only have two members preprovisioned in the Routing Engine role. If more than two Routing Engines are configured, NSSU issues a warning message and the NSSU process stops.

  • The VCF members should be connected in a spine and leaf topology. A spine and leaf topology prevents the VCF from splitting during NSSU. Each leaf device must be connected to both spine devices.

  • The VCF must be preprovisioned so that the line-card role has been explicitly assigned to member switches acting in a line-card role, and likewise the Routing Engine role has been explicitly assigned to the member switches acting in a Routing Engine role. During an NSSU, the primary and backup member switches must maintain their Routing Engine roles (although the primary role switches to the backup), and the remaining switches must maintain their line-card roles.

  • You must configure no-split-detection in a two-member VCF so the VCF does not split during NSSU.

Options

Required Privilege Level

maintenance

Output Fields

This command reports feedback on the status of the request. Some functions are shared between NSSU and the in-service software upgrade (ISSU) feature, so you might see what appear to be ISSU messages as well as NSSU messages in the output from this command.

Sample Output

• request system software nonstop-upgrade (EX4200 Virtual Chassis)
• request system software nonstop-upgrade (EX6200 Switch)
• request system software nonstop-upgrade reboot (EX8200 Switch)
• request system software nonstop-upgrade no-old-master-upgrade (EX8200 Switch)
• request system software nonstop-upgrade reboot (EX8200 Virtual Chassis)

Release Information

Command introduced in Junos OS Release 10.4.

Option set [package-name package-name] added in Junos OS Release 12.1 for EX Series switches.