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. |
| Note:
|
Published: 2014-06-19
Related Documentation
- SRX Series
- Upgrading Both Devices in a Chassis Cluster Using ICU
- Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis Cluster
- Upgrading ICU Using a Build Available on an FTP Server
- Additional Information
- Chassis Cluster Feature Guide for Security Devices
