Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Upgrade Firewalls in a Chassis Cluster Using ICU

This topic explains the chassis cluster In‑Service Chassis Upgrade (ICU) method, which enables both devices in a cluster to be upgraded from supported Junos OS versions by using a single command. The ICU method automates the upgrade process across the cluster, simplifying operations and reducing administrative effort.

For SRX300, SRX320, SRX340, SRX345, and SRX380 Firewalls, if you are upgrading to Junos OS Release 24.4R1, you cannot use the ICU method. You must use either the procedures outlined in KB 85650 or the minimal downtime procedure documented in KB17947 (Minimal_Downtime_Upgrade_Branch_Mid PDF file). Once you have upgraded to Junos OS Release 24.4R1, you can use the ICU method to upgrade to any later releases or downgrade from one of those later releases to either Junos OS Release 23.4R2-S3 or to Release 24.2R2.

Upgrade Both Devices in a Chassis Cluster Using ICU

Before starting ICU, note the following:

Firewalls in a chassis cluster can be upgraded with minimal service disruption by using the In-Band Cluster Upgrade (ICU) feature. The chassis cluster ICU capability allows both devices in a cluster to be upgraded from supported Junos OS versions by issuing a single command.

To enable ICU, execute the following command on the primary node:request system software in-service-upgrade image_name.

This command initiates the upgrade process by installing the specified Junos OS image and rebooting the secondary node first, followed by the primary node. During the ICU process, traffic disruption is minimal because traffic fails over between cluster nodes as upgrades occur. However, cold synchronization is not supported between the two nodes during the ICU procedure.

For SRX300, SRX320, SRX340, SRX345, and SRX380 devices, Firewalls in a chassis cluster can be upgraded with minimal service disruption of approximately 30 seconds by using the ICU with the no-sync option. The chassis cluster ICU feature enables both devices in the cluster to be upgraded from supported Junos OS versions as part of a coordinated upgrade process.

This method significantly reduces traffic impact during the upgrade while simplifying operational procedures.

On SRX1500 devices, you must use the in-band cluster upgrade (ICU) commands to upgrade between the following Junos OS Releases:

  • Junos OS Release 15.1X49-D50 to Junos OS Release 15.1X49-D100

  • Junos OS Release 15.1X49-D60 to Junos OS Release 15.1X49-D110

  • Junos OS Release 15.1X49-D50 to Junos OS Release 15.1X49-D120

You must use the in-band cluster upgrade (ICU) commands on SRX1600 device to upgrade from Junos OS Release 23.3R1 to later release.

You can use the in-band cluster upgrade (ICU) commands on SRX2300, SRX4120,SRX4100 and SRX4200 devices to upgrade following Junos OS Releases:

  • Junos OS Release 15.1X49-D65 to Junos OS Release 15.1X49-D70

  • Junos OS Release 15.1X49-D70 to Junos OS Release 15.1X49-D80.

For SRX300, SRX320, SRX340, SRX345 and SRX380 devices, the impact on traffic is as follows:

  • Drop in traffic (30 seconds approximately)

  • Loss of security flow sessions

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 with one exception being the SRX1500 and SRX1600. ICU will not continue if it fails to detect dual-root partitioning on either of the nodes. Requirement of the dual-root partitioning is applicable only for SRX300, SRX320, SRX340, SRX345, and SRX380 devices.

    SRX1500 and SRX1600 use solid-state drive (SSD) as secondary storage.

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

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:

  1. 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.
  2. Start ICU by entering the following command:

    user@host> request system software in-service-upgrade image_name no-sync (On SRX300, SRX320, SRX340, SRX345, and SRX380 Firewalls)

    user@host> request system software in-service-upgrade image_name (On SRX1500 Firewall prior to Junos OS Release 18.1R1)

    user@host> request vmhost software in-service-upgrade image_name (On SRX1600 and SRX2300, SRX4120 Firewalls)

Upgrade ICU Using a Build Available on an FTP Server

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 using ICU with a build available on an FTP server:

  1. Place the Junos OS build on an FTP server that is reachable from the chassis cluster devices.
  2. On SRX300, SRX320, SRX340, SRX345 and SRX380 Firewalls, start the ICU process by entering the following command:

    user@root> request system software in-service-upgrade <ftp url for junos image> no-sync

    Sample Command

    This command upgrades the Junos OS and reboots both nodes in turn.

  3. On SRX1500 only, prior to Junos OS Release 15.1X49-D70, start the ICU process by entering the following command:

    user@root> request system software in-service-upgrade <ftp url for junos image>

    Sample Command

    This command upgrades the Junos OS and reboots both nodes in turn.

    On SRX1600, SRX2300, and SRX4120 Firewalls, start ICU by entering the following command:

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.

Terminate an Upgrade in a Chassis Cluster During an ICU

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

request system software abort in-service-upgrade

Issuing the abort command during or after the secondary node reboots can place the chassis cluster in an inconsistent state. In this condition, the secondary node boots with the new Junos OS image, while the primary node continues to run the older Junos OS image.

To recover and restore consistency in the chassis cluster, perform the following actions sequentially on the secondary node:

  1. Issue an abort command:

    request system software abort in-service-upgrade

  2. Roll back the Junos OS build by entering the following command:

    request system software rollback node < node-id >

  3. Reboot the secondary node by using the following command:

    request system reboot

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.

The ICU no-sync option is supported only on SRX300, SRX320, SRX340, SRX345, and SRX380 Firewalls

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 a termination command is executed, ICU will terminate 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 terminates after this operation finishes.

  • After a termination, ICU will try to roll back the build on the nodes if the upgrading nodes step was completed.

Related Documentation