TechLibrary

Table of Contents

Guide That Contains This Content

[+] Expand All

[-] Collapse All

Upgrading Devices in a Chassis Cluster Using ICU

Upgrading Both Devices in a Chassis Cluster Using ICU

Devices in a chassis cluster can be upgraded with a minimal service disruption of approximately 30 seconds using in-band cluster upgrade (ICU) with the no-sync option. The chassis cluster ICU feature allows both devices in a cluster to be upgraded from supported Junos OS versions.

The impact on traffic is as follows:

Drop in traffic (30 seconds approximately)
Loss of security flow sessions

Note: ICU is supported only on SRX100, SRX210, SRX220, SRX240, and SRX650 Services Gateways.

Before you begin, note the following:

ICU is available with the no-sync option only.
This feature is available only on Junos OS Releases 11.2 R2 and later.
Before starting ICU, you should ensure that sufficient disk space is available. See Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis Cluster and Upgrading ICU Using a Build Available on an FTP Server.
This feature cannot be used to downgrade to a build earlier than Junos OS 11.2 R2.

The upgrade is initiated with the Junos OS build locally available on the primary node of the device or on an FTP server.

The primary node, RG0, changes to the secondary node after an ICU upgrade.
During ICU, the chassis cluster redundancy groups are failed over to the primary node to change the cluster to active/passive mode.
ICU states can be checked from the syslog or with the console/terminal logs.
ICU requires that both nodes be running a dual-root partitioning scheme. ICU will not continue if it fails to detect dual-root partitioning on either of the nodes.

Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis Cluster

Note: Ensure that sufficient disk space is available for the Junos OS package in the /var/tmp location in the secondary node of the cluster.

To upgrade ICU using a build locally available on the primary node of a cluster:

Copy the Junos OS package build to the primary node at any location, or mount a network file server folder containing the Junos OS build.
Start ICU by entering the following command:
user@host> request system software in-service-upgrade image_name no-sync

Upgrading ICU Using a Build Available on an FTP Server

Note: Ensure that sufficient disk space is available for the Junos OS package in the /var/tmp location in both the primary and the secondary nodes of the cluster.

To upgrade ICU using a build available on an FTP server:

Place the Junos OS build on an FTP server.
Start ICU by entering the following command:
user@root> request system software in-service-upgrade <ftp url for junos image> no-sync
Sample Command
user@root> request system software in-service-upgrade ftp://<user>:<password>@<server>:/<path> no-sync
This command upgrades the Junos OS and reboots both nodes in turn.

Note: The upgrade process displays the following warning message to reboot the system:

WARNING: A reboot is required to load this software correctly. Use the request system reboot command when software installation is complete.

This warning message can be ignored because the ICU process automatically reboots both the nodes.

Aborting an Upgrade in a Chassis Cluster During an ICU

You can abort an ICU at any time by issuing the following command on the primary node:

request system software abort in-service-upgrade

Note: Issuing an abort command during or after the secondary node reboots puts the cluster in an inconsistent state. The secondary node boots up running the new Junos OS build, while the primary continues to run the older Junos OS build.

To recover from the chassis cluster inconsistent state, perform the following actions sequentially on the secondary node:

Issue an abort command:
request system software abort in-service-upgrade
Roll back the Junos OS build by entering the following command:
request system software rollback node < node-id >
Reboot the secondary node immediately by using the following command:
request system reboot

Note: You must execute the above steps sequentially to complete the recovery process and avoid cluster instability.

Table 1 lists the options and their descriptions for the request system software in-service-upgrade command.

Table 1: request system software in-service-upgrade Output Fields

Options	Description
no-sync	Disables the flow state from syncing up when the old secondary node has booted with a new Junos OS image.
no-tcp-syn-check	Creates a window wherein the TCP SYN check for the incoming packets will be disabled. The default value for the window is 7200 seconds (2 hours).
no-validate	Disables the validation of the configuration at the time of the installation. The system behavior is similar to software add.
unlink	Removes the package from the local media after installation.

During ICU, if an abort command is executed, ICU will abort only after the current operation finishes. This is required to avoid any inconsistency with the devices.
For example, if formatting and upgrade of a node is in progress, ICU aborts after this operation finishes.
After an abort, ICU will try to roll back the build on the nodes if the upgrading nodes step was completed.