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.
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.
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
Once all redundancy groups are active on one device, the upgrade is initiated by using a request command:
If reboot is not included in the command, you will need to manually reboot each device as the ISSU completes updating the software image.
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.
If the ISSU fails to complete and only one device in the cluster has been upgraded, you can roll back to the previous configuration on that device alone by using the following commands on the upgraded device:
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:
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.
If you want redundancy groups to automatically return to node 0 as the primary after the ISSU is complete, you must set the redundancy group priority such that node 0 is primary and enable the preempt option. Note that this method will work for all redundancy groups except redundancy group 0. You must manually fail over redundancy group 0. To set the redundancy group priority and enable the preempt option, see Configuring Redundancy Groups. To manually fail over a redundancy group, see Initiating a Manual Redundancy Group Failover.
Certain circumstances might cause an ISSU attempt to fail. This section explains two of them.
When using dual control links (supported on the SRX5000 and SRX3000 lines only), mismatched control link statistics might be reported with the show chassis cluster statistics and show chassis cluster control-plane statistics commands while you run an ISSU with nodes on devices running different releases. (ISSUs are available in JUNOS Release 9.6 and later and dual control links are available in JUNOS Release 10.0 and later.) For example, assume that one node on a device is running JUNOS Release 9.6 and another node on a device is running JUNOS Release 10.0. In this example, a mismatch might occur because the latter device will be sending heartbeats on both control links, but the other device will receive heartbeats only on one control link.