[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Upgrading Devices in a Chassis Cluster

Devices in a chassis cluster can be upgraded separately one at a time; some models allow one device after the other to be upgraded using failover and an in-service software upgrade (ISSU) to reduce the operational impact of the upgrade.

Upgrading Each Device Separately

To upgrade each device in a chassis cluster separately:

Note: During this type of chassis cluster upgrade, a service disruption of about 3 to 5 minutes will occur.

  1. Load the new image file on node 0.
  2. Perform the image upgrade without rebooting the node by entering:
    user@host> request system software add image_name
  3. Load the new image file on node 1.
  4. Repeat Step 2.
  5. Reboot both nodes simultaneously.

Low-Impact ISSU Chassis Cluster Upgrades

For some platforms, devices in a chassis cluster can be upgraded without a service disruption using an in-service software upgrade (ISSU). The chassis cluster ISSU feature allows both devices in a cluster to be upgraded or downgraded from supported JUNOS versions with a traffic impact similar to that of redundancy group failovers.

Before You Begin
  1. Note that in-service software upgrades (ISSUs) are available only for JUNOS Software Release 9.6 and later.
  2. Before starting an ISSU, you should fail over all redundancy groups so that they are all active on only one device. See Initiating a Manual Redundancy Group Failover for more information.
  3. We also recommend that graceful Routing Engine switchover (GRES) be enabled prior to starting an ISSU.

Once all redundancy groups are active on one device, the upgrade is initiated by using a request command:

  1. Fail over all redundancy groups to one device.
  2. Start the ISSU by entering the following command:
    user@host> request system software in-service-upgrade image_name
  3. Wait for both devices to complete the upgrade, then verify that all policies, zones, redundancy groups, and other runtime objects (RTOs) return to their correct states. Also verify that both devices in the cluster are running the new JUNOS Software build.

Note: During the upgrade, both devices might experience redundancy group failovers, but traffic will not be disrupted. Each device validates the package and checks version compatibility before doing the upgrade. If the system finds that the new package is not version compatible with the currently installed version, the device will refuse the upgrade, or prompt you to take corrective action. Sometimes a single feature is not compatible, in which case the upgrade software will prompt you to either abort the upgrade or turn off the feature before doing the upgrade.

The ISSU command has one option: no-old-master-upgrade. This option leaves the current master device in a nonupgraded state, which is a precaution against service failure. The no-old-master-upgrade option allows routing control to be quickly returned to the old master device if the newly upgraded device does not operate correctly.

Use of the no-old-master-upgrade option will require you to run a standard upgrade on the old master device after the ISSU is completed on the backup device.

If you use the no-old-master-upgrade option, when the backup device completes its upgrade and you are confident that the new build is operating as expected, then upgrade the old master as follows:

  1. Run request system software add image_name
  2. Run request chassis cluster in-service-upgrade abort to stop the ISSU process.
  3. Run request system reboot

This feature is available only via the command-line interface. See the “request system software in-service-upgrade” section of the JUNOS Software CLI Reference.

Troubleshooting ISSU Failure

Certain circumstances might cause an ISSU attempt to fail. This section explains two of them.

Related Topics

[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]