Upgrading the vSRX Virtual Firewall in IBM Cloud
Upgrading
There are several methods and considerations that you must understand before upgrading your IBM Cloud® Juniper vSRX Virtual Firewall:
vSRX Virtual Firewall 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 Virtual Firewall. The table also describes whether rollback is supported for the upgrade. Additional considerations include whether you need a manual vSRX Virtual Firewall configuration migration to complete the upgrade.
Reference the following table to determine if you can upgrade your vSRX Virtual Firewall using OS reload. For more information, see General upgrade considerations.
For more information on the vSRX Virtual Firewall versions listed below, see IBM Cloud Juniper vSRX supported versions.
Current vSRX Virtual Firewall 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 Virtual Firewall upgrade, be aware of the following considerations:
You might experience network disruptions when upgrading your vSRX Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall configuration.
For a successful reload on a HA vSRX Virtual Firewall, the root password for the provisioned vSRX Virtual Firewall gateway must match the root password that is defined in the vSRX Virtual Firewall portal. In addition, you must enable root SSH login to the vSRX Virtual Firewall 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 Virtual Firewall gateway and change the root password to match. The Readiness Check fails if there is a password mismatch.
Do not modify the vSRX Virtual Firewall configuration during an OS reload. The upgrade process captures a snapshot of the current vSRX Virtual Firewall cluster configuration at the beginning of the process. Therefore, modifying the vSRX Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall gateway instances in the same pod, make sure that only one gateway is upgraded at a time. Upgrading more than one vSRX Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall configuration and migrate the settings to the new architecture if necessary.
vSRX Virtual Firewall Migration Configuration Considerations
For a High Availability environment, the upgrade restores the previous vSRX Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall version.
Before restoring the original vSRX Virtual Firewall image, rename the vSRX Virtual Firewall 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 Virtual Firewall version.
The cluster will now be running with its original configuration.
Unsupported Upgrades
Early deployments of 1G vSRX Virtual Firewall 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 Virtual Firewall versions, such as 19.4, require the SR-IOV networking design. Therefore, vSRX Virtual Firewall version upgrades are not supported for deployments based on this 1270v6 processor.
To upgrade to a newer vSRX Virtual Firewall version, such as 19.4, you must place a new vSRX Virtual Firewall 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 Virtual Firewall. For more information, see Migrating Legacy Configurations to the Current vSRX Architecture.