ISSU: Overview and procedure for In-Service Software Upgrade

This article provides an overview and procedure for the In-Service Software upgrade.

In-Service Software Upgrade (ISSU) procedure, along with information on the precautionary actions to take.

ISSU Overview

In-Service Software Upgrade (ISSU) is a deployment technique which allows you to upgrade Junos software releases with no disruption to the Control Plane and minimal disruption to the Traffic. ISSU daemon functions in a fashion that upgrades the secondary node first before upgrading the primary node, and thus ensures minimum loss of traffic during the process.

Note: ISSU can be performed, only when upgrading to a software version that is newer than the currently installed version on the device. Trying to upgrade to an older version of software will cause ISSU to abort.

It is of utmost importance that a user should evaluate the ISSU solution and understand the process behind ISSU, before attempting to proceed.

However, as of Junos 11.1, the ISSU upgrade limitations for NAT and ALG are resolved; but the VPN configuration could still cause issues. It is necessary to check the release documents of the version from and to which the upgrade is to be done. If your organization still requires the ISSU upgrade process, for minimal traffic disruption, follow this guide.

An alternate to ISSU is the Minimum Downtime Method upgrade.

General idea on what happens when ISSU is initiated:

When the ISSU daemon is initiated, it automatically pushes the software package from the primary to the secondary, first performs the upgrade on the secondary, and does a reboot on the secondary. When the secondary comes back up and after all the FPC and related hardware is online, the current primary will perform a failover, making it the secondary, and the other node becomes the primary.

Traffic will continue to go through the new primary (which was the secondary earlier) at this point. After this, the ISSU will continue to upgrade node 0 and reboot that part of the cluster. When the failover happens, make sure that both the Routing Engine and the fabric has failed over (that is, All RG’s should have failed over).

Caveats and recommendations before proceeding:

  • ISSU is not recommended for high-end SRX devices that run 10.2 and 10.1. There are additional limitations, based on the features that are enabled in the configuration.
  • ISSU is not supported on branch devices.

Important: Even though it is stated there will be minimum impact, it would be better if the failover part of it occurs during a Maintenance Window. This is just as a precautionary step to minimize any ancillary impact.

Proceeding with In-Service Software Upgrade:

When the caveats of the process are understood, proceed with the In-Service Software Upgrade. The process by itself is very simple and Junos makes it possible for a complete semi-automated upgrade of both nodes by using ISSU. The procedure is as follows:

1.Load the Junos Software package on the device –

2.Verify the Health of the Cluster (This is an important step and the cluster needs to be certified healthy before proceeding with In-Service Software Upgrade)

3.Create backup of the current configuration and set the rescue config

4.Start the In-Service Software Upgrade

5.Process to follow, in the event of the ISSU process stalling in the middle of the upgrade

About the author


Leave a Comment