JunOS versions on Branch devices (SRX100, SRX210, SRX220, SRX240, SRX550, and SRX650 Services Gateways) in a chassis cluster can be upgraded using in-band cluster upgrade (ICU) method. Downtime required for this type of upgrade method is less than 30 seconds.

Notes


  • Drop in traffic (30 seconds approximately)

  • Loss of security flow sessions. ICU is available with the no-sync option only. Ie; flow states will not be synced to secondary node when one node is rebooting while upgrading.

  • ICU method is available only on Junos OS releases 11.2R2 and later

  • ICU method cannot be used to downgrade to a build earlier than Junos OS 11.2R2

  • Make sure sufficient disk spaces are available on both nodes.


Upgrade Steps


1 Confirm Junos OS Version running on the devices

$ show version

2 Confirm serial console access to the devices

3 Perform storage clean-up

$ request system storage cleanup

4 Upload latest Junos OS to /var/tmp of node0

5 Perform ICU upgrade

$ request system software in-service-upgrade <image_name> no-sync

6 Monitor the upgrade process in console session


Upgrade Procedure + Console logs


Validate package and copy to secondary node

ISSU: Validating package WARNING: in-service-upgrade shall reboot both the nodes in your cluster. Please ignore any subsequent reboot request message ISSU: start downloading software package on secondary node Pushing bundle to node1

Create alternate root partition and extract the image to alternate root partition

Formatting alternate root (/dev/da0s1a)… /dev/da0s1a: 296.9MB (607996 sectors) block size 16384, fragment size 2048 Extracting /var/tmp/junos-srxsme-12.1X46-D55.3-domestic.tgz …

ISSU upgrades secondary and then primary node

JUNOS 12.1X46-D55.3 will become active at next reboot ISSU: finished upgrading on secondary node node1 ISSU: start upgrading software package on primary node JUNOS 12.1X46-D55.3 will become active at next reboot

Fail over all redundancy groups to node0

ISSU: failover all redundancy-groups 1…n to primary node Successfully reset all redundancy-groups priority back to configured priority. node1: ————————————————————————– Successfully reset all redundancy-groups priority back to configured priority. node0:  ————————————————————————– Initiated manual failover for all redundancy-groups to node0

Reboot secondary node

ISSU: rebooting Secondary Node

Reboot primary node, when secondary node is back online

ISSU: Waiting for secondary node node1 to reboot. ISSU: Waiting for node 1 to come up ISSU: node 1 came up ISSU: secondary node node1 booted up.


Aborting ICU upgrade


At any time during the upgrade process, you can abort by running

request system software abort in-service-upgrade


If you have given the abort command during / after secondary node reboots. Your cluster will be un an inconsistent state. ie; secondary node will be running with new version than primary node. You should rollback the upgrade on secondary node by running following commands.


Abort upgrade

request system software abort in-service-upgrade

Roll back to previous node

request system software rollback node < node-id >

Reboot node

request system reboot


Ref:

  • Juniper KB Articles [SRX] ISSU/ICU upgrade limitations on SRX firewalls
  • Upgrading Devices in a Chassis Cluster Using ICU


Happy Upgrade :)


Dijeesh Padinharethil

Associate Director, Cloud Services @ Network Redux

Infrastructure | Operations | AWS | DevOps Engineer