Upgrading Both Devices in a Chassis Cluster Using an ISSU
The chassis cluster ISSU feature allows both devices in a cluster to be upgraded from supported Junos OS versions with a traffic impact similar to that of redundancy group failovers.
Before you begin, note the following guidelines:
- Back up the software using the request system snapshot command on each Routing Engine to back up the system software to the device’s hard disk
- If you are using Junos OS Release 11.4 or earlier, before
starting an ISSU, fail over all redundancy groups so that they are
all active on only one node (primary). See Initiating a Chassis Cluster Manual Redundancy Group Failover
If you are using Junos OS Release 12.1 or later, Junos OS software will automatically fails over all RGs to the RG0 primary.
- We recommend that you enable graceful restart for routing protocols before you start an ISSU.
 | Note: On all high-end SRX Series devices, the first recommended unified ISSU from release is Junos OS Release 10.4R4. |
To perform an ISSU from the CLI:
- Download the software package from the Juniper Networks Support website.
- Copy the package on both nodes of the cluster. We recommend
that you copy it to the /var/tmp directory, which is a large file
system on the hard disk. Note that the node from where you initiate
the ISSU must have the software image.
user@host>file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp/filename
- Verify the current software version running on both nodes. On the primary node, issue the show version command.
- Start the ISSU from the node that is primary for all the
redundancy groups by entering the following command:
user@host> request system software in-service-upgrade image-name-with-full-path rebootNote: For SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, you must include reboot in the command. If reboot is not included, the command fails. For SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices, the reboot parameter is not available because the devices in a cluster are automatically rebooted following an in-band cluster upgrade (ICU).
Wait for both nodes to complete the upgrade (you are logged out of the device).
- Wait a few minutes, and then log in to the device again. Verify that both devices in the cluster are running the new Junos OS build using the show version command.
- Verify that all policies, zones, redundancy groups, and other RTOs return to their correct states.
- Make node 0 the primary node again by issuing the request chassis cluster failover node node-number redundancy-group group-number command.
| Note: 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 works 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 Example: Configuring Chassis Cluster Redundancy Groups. To manually fail over a redundancy group, see Initiating a Chassis Cluster Manual Redundancy Group Failover. |
| Note: During the upgrade, both devices might experience redundancy group failovers, but traffic is not 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 refuses the upgrade or prompts you to take corrective action. Sometimes a single feature is not compatible, in which case the upgrade software prompts you to either abort the upgrade or turn off the feature before doing the upgrade. |
This feature is available only through the command-line interface. See request system software in-service-upgrade .
