Upgrading Software on a Virtual Chassis and Mixed Virtual Chassis Using Nonstop Software Upgrade

Before you begin installing the new software using NSSU:

• Ensure that the Virtual Chassis is connected and configured correctly to support the NSSU process. See Requirements for Performing an NSSU.

• Verify that the members are running the same version of the software:

  If the Virtual Chassis or mixed Virtual Chassis members are not running the same version of the software, use the request system software add command to upgrade the software on the inconsistent members.

• Ensure that graceful Routing Engine switchover (GRES) is enabled, or for applicable platforms, make sure nonstop active routing (NSR) is enabled, which also enables graceful Routing Engine switchover. See Configuring Nonstop Active Routing on Switches for more information.

  To check the nonstop active routing state to verify both NSR and GRES are enabled:

• (Optional for applicable platforms) Enable nonstop bridging (NSB), which ensures that all NSB-supported Layer 2 protocols operate seamlessly during the Routing Engine switchover that is part of the NSSU. See Configuring Nonstop Bridging on Switches (CLI Procedure) for details.

• For a two-member Virtual Chassis, make sure you configured no-split-detection so the Virtual Chassis does not split when NSSU upgrades one of the members. See Disabling Split and Merge in a Virtual Chassis.

• In an EX4300 Virtual Chassis running a Junos OS 13.2X50 release, you should set the vcp-no-hold-time option at the [edit virtual-chassis] hierarchy level before performing a software upgrade using NSSU, otherwise the Virtual Chassis might split during the upgrade. A split Virtual Chassis can disrupt your network, and you might need to manually reconfigure your Virtual Chassis after the NSSU if the split-and-merge feature was disabled. For more information about a Virtual Chassis split, see Understanding Split and Merge in a Virtual Chassis. This statement only affects EX4300 Virtual Chassis or mixed Virtual Chassis that contain EX4300 switches.

  To configure this option:

• On a QFX5100 Virtual Chassis with line-card upgrade groups configured, you should enable the lc-reboot-delay option to configure a delay for when adjacent members in a line card group reboot. Without this option, when the next member reboots, approximately two minutes after the previous member reboots and joins the Virtual Chassis, the previous rebooted member might not be ready to carry traffic. This delay helps prevent dropping traffic when there are two adjacent line card members with interfaces that are part of a common link aggregation group (LAG).

  We recommend setting a 200-second delay (the allowable range is 0 to 600 seconds). To configure this delay:

• (Optional) Back up the system software (Junos OS, the active configuration, and log files) on each member to an external storage device as desired using the request system snapshot command.

To upgrade all members in a Virtual Chassis using NSSU:

1. Download the software package as described in Installing Software Packages on QFX Series Devices. If you are upgrading a mixed Virtual Chassis, download the software packages for the different switch types.

2. Copy the software package or packages to the Virtual Chassis. We recommend that you copy the file or files to the /var/tmp directory on the primary.

3. Use the console connection or the virtual management Ethernet (VME) interface to log in to the Virtual Chassis or mixed Virtual Chassis. You can monitor the progress of the primary switch reboot if you use a console connection.

4. Start the NSSU:

   • On a Virtual Chassis where all members use the same software image, enter:

     where package-name.tgz is the software package name, for example, jinstall-qfx-3-13.2X50-D15.3-domestic-signed.tgz.

   • On a mixed Virtual Chassis where members might use different software images, enter the request system software nonstop-upgrade command with the set option to specify more than one software package name:

     For example, /var/tmp/package-name1.tgz and /var/tmp/package-name2.tgz might specify software packages for EX4200 and EX4500 switches in a mixed EX Series Virtual Chassis with EX4200 and EX4500 switches.

   The switch displays status messages similar to the following messages as the upgrade executes:

5. Log in after the original primary switch reboot completes. To verify that the software is upgraded on all Routing Engines in the Virtual Chassis, enter the following command:

6. To ensure the resilient dual-root partitions feature operates correctly, copy the new Junos OS image into the alternate root partitions of all members:

   With resilient dual-root partitions, the switch can boot transparently from the alternate root partition if the system fails to boot from the primary root partition.