Upgrading the vSRX in IBM Cloud
Upgrading
There are several methods and considerations that you must understand before upgrading your IBM Cloud® Juniper vSRX:
vSRX version level
Bare-metal server processor model
Bandwidth: 1G versus 10G
Stand-alone or High Availability (HA)
Using these factors, the following table lists whether you can use the OS reload option to upgrade your vSRX. The table also describes whether rollback is supported for the upgrade. Additional considerations include whether you need a manual vSRX configuration migration to complete the upgrade.
Reference the following table to determine if you can upgrade your vSRX using OS reload. For more information, see General upgrade considerations.
For more information on the vSRX versions listed below, see IBM Cloud Juniper vSRX supported versions.
Current vSRX Version |
Processor Model and Speed |
Stand-Alone or HA |
Upgrade method |
Rollback supported |
|---|---|---|---|---|
15.1 |
1270v6 (All 1G deployments) |
Stand-alone and HA |
Not Supported |
N/A |
15.1 |
All 10G Deployments |
Stand-alone and HA |
Stand-alone: No HA:
|
|
18.4 |
1270v6 (Some 1G Deployments) |
Stand-alone and HA |
Not Supported |
N/A |
18.4 |
4210 (Some 1G Deployments) |
Stand-alone |
No |
|
18.4 |
4210 (Some 1G Deployments) |
HA |
|
|
18.4 |
All 10G Deployments |
Stand-alone |
No |
|
18.4 |
All 10G Deployments |
HA |
|
|
19.4 and newer |
All 1G and 10G Deployments |
Stand-alone and HA |
Yes – Manual (not automated) rollbacks are allowed after the first server completes the OS reload. For more information, see Rollback Options. |
General Upgrade Considerations
Before you perform a vSRX upgrade, be aware of the following considerations:
You might experience network disruptions when upgrading your vSRX version. To avoid disruptions, perform the upgrade during a maintenance window that supports potential network downtime. Failover is not available until the upgrade completes, and can take several hours. For High Availability (HA) environments, your vSRX configuration settings are migrated; however, it is recommended to export your settings before the upgrade.
For a stand-alone environment, the previous configuration is not restored, so you should export and import your configuration. For more information, see Importing and exporting a vSRX configuration.
For a successful reload on a HA vSRX, the root password for the provisioned vSRX gateway must match the root password that is defined in the vSRX portal. In addition, you must enable root SSH login to the vSRX Private IP.
Note:You defined the password in the portal when you provisioned your gateway. This might not match the current gateway password. If the password was changed after provisioning, then use SSH to connect to the vSRX gateway and change the root password to match. The Readiness Check fails if there is a password mismatch.
Do not modify the vSRX configuration during an OS reload. The upgrade process captures a snapshot of the current vSRX cluster configuration at the beginning of the process. Therefore, modifying the vSRX configuration during the upgrade process can result in a failure, or unpredictable results. For example, automated software agents attempting to modify one or both vSRX nodes. Configurations changes can corrupt the OS reload process. Additionally, these configuration changes are not preserved if a rollback is initiated.
Before performing an OS reload upgrade on an HA cluster, run the command show chassis cluster status. The nodes should be clustered with one node that is listed as the primary and the other as secondary. Ensure that there are no monitor failures. If the cluster is not healthy prior to the upgrade, then the upgrade can fail, causing an extended traffic outage.
Example of a healthy cluster:
root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status Monitor Failure codes: CS Cold Sync monitoring FL Fabric Connection monitoring GR GRES monitoring HW Hardware monitoring IF Interface monitoring IP IP monitoring LB Loopback monitoring MB Mbuf monitoring NH Nexthop monitoring NP NPC monitoring SP SPU monitoring SM Schedule monitoring CF Config Sync monitoring RE Relinquish monitoring IS IRQ storm Cluster ID: 2 Node Priority Status Preempt Manual Monitor-failures Redundancy group: 0 , Failover count: 1 node0 100 primary no no None node1 1 secondary no no None Redundancy group: 1 , Failover count: 1 node0 100 primary no no None node1 1 secondary no no None {primary:node0} Example of an unhealthy cluster with monitor failures: root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status Monitor Failure codes: CS Cold Sync monitoring FL Fabric Connection monitoring GR GRES monitoring HW Hardware monitoring IF Interface monitoring IP IP monitoring LB Loopback monitoring MB Mbuf monitoring NH Nexthop monitoring NP NPC monitoring SP SPU monitoring SM Schedule monitoring CF Config Sync monitoring Cluster ID: 3 Node Priority Status Preempt Manual Monitor-failures Redundancy group: 0 , Failover count: 1 node0 0 lost n/a n/a n/a node1 1 primary no no None Redundancy group: 1 , Failover count: 1 node0 0 lost n/a n/a n/a node1 0 primary no no CS {primary:node1}If your IBM Cloud account has multiple vSRX gateway instances in the same pod, make sure that only one gateway is upgraded at a time. Upgrading more than one vSRX at a time can result in IP collisions, disrupt the upgrade process, and potentially cause failures.
For HA clusters, the upgrade process requires you to disable the vSRX Chassis Cluster preemption flag for Redundancy Group 1. Therefore, after the upgrade completes, the flag is disabled, but you can enable again. Run show chassis cluster status to view the preempt setting.
Upgrading using OS Reload
To upgrade your vSRX using OS reload, perform the following procedure.
Standalone environment only: See Exporting part of the vSRX configuration.
Access the gateway details page, see Viewing gateway appliance details.
Run a readiness check for “OS reload”. See Checking vSRX readiness and address any errors that are found.
Perform an OS reload for each bare metal server. See Performing an OS reload.
Note:When upgrading an HA cluster, the process will power off the node not undergoing the OS reload at the end of the upgrade process. This will transition the cluster’s primary node and any active network traffic to the newly upgraded one. Once the OS reload completes for the first node in the cluster, it is critical that the second node be left unpowered until the OS reload to upgrade that node is submitted and running. Powering the node on prior to the OS reload will cause the cluster to run with mismatched vSRX versions, potentially leading to a “split-brain” scenario where each node tries to claim primary ownership. This generally results in an outage. After the OS reload of the first node, the gateway will transition to “Upgrade Active” status.
Standalone environment only: Import the vSRX configuration and migrate the settings to the new architecture if necessary.
vSRX Migration Configuration Considerations
For a High Availability environment, the upgrade restores the previous vSRX configuration. No further steps are needed.
For a Standalone environment, the upgrade does not restore the previous configuration, so you should export and import your configuration. See Importing and and exporting a vSRX Configuration for more information.
Additionally, when migrating from an older version, such as 15.1, your interface mappings may have changed. This requires some modifications to the vSRX configuration after the import. See Migrating 1G vSRX standalone configurations for more information.
Rollback Options
In the standalone environment a rollback is not supported.
In the high availability environment that is upgrading from vSRX version, a rollback is supported only after the first node has been OS Reloaded and before the second node has been OS Reloaded. The Gateway will be in an “Upgrade Active” state at this point. The following steps should be followed to rollback the first node to the previous version.
Please be aware that a traffic disruption will occur while waiting for the secondary node to power on and for the traffic to failover to this node.
Power off the vSRX on the node being rolled-back (primary node) using the command virsh shutdown <domain> Wait for the node to be fully powered off before proceeding.
Power up the vSRX on the node that has not been rolled-back using the command virsh start <domain>. Doing so will return the primary node back to the original vSRX version.
Before restoring the original vSRX image, rename the vSRX qcow2 file in /var/lib/libvirt/images/vSRXvM2/vSRX_Image.qcow2.backup to /var/lib/libvirt/images/vSRXvM2/vSRX_Image.qcow2 so that virsh detects the original image.
Run the OS reload readiness checks, see Checking vSRX readiness if necessary, and resolve any issues.
Perform an OS reload on the host you want to rollback to return it to the original vSRX version.
The cluster will now be running with its original configuration.
Unsupported Upgrades
Early deployments of 1G vSRX 15.1 and 18.4 gateways used a networking design based on Linux Bridging. Newer 1G deployments use a networking design based on SR-IOV. For more information, see Understanding the vSRX default configuration.
Early 1G deployments generally used an Intel 1270v6 4-Core, Sky-Lake-based processor. This processor does not support SR-IOV. Newer vSRX versions, such as 19.4, require the SR-IOV networking design. Therefore, vSRX version upgrades are not supported for deployments based on this 1270v6 processor.
To upgrade to a newer vSRX version, such as 19.4, you must place a new vSRX order. After completion, you can migrate the configuration from the old design to the new, but you must also apply some manual configuration changes to the new vSRX. For more information, see Migrating Legacy Configurations to the Current vSRX Architecture.