Upgrading by using OS reload

This document outlines the process to update the Junos version for both stand-alone and high-availability (HA) vSRX gateway appliance deployments. The upgrade also includes deploying a specific, tested Ubuntu version paired with the Junos version. Review the complete process outlined in the following sections before you start your Juniper vSRX upgrade maintenance window.

The stand-alone vSRX upgrade is highly impactful, causing traffic downtime during the reload and reconfiguration. You must manually back up and restore the configuration because the upgrade process erases all configurations.

Upgrading a stand-alone vSRX deployment

To upgrade a stand-alone vSRX deployment, follow these steps:

Export the current vSRX configuration: Back up the settings before you start the deployment because the reload removes all configurations.
Access the gateway details page: View the gateway appliance's specifics by navigating to its details page.
Run a Readiness check for “Version upgrade” and address any errors that are found.

Run the readiness check several hours before the maintenance so that any outstanding access and configuration requirements are addressed before the upgrade maintenance. Readiness checks take about 30 minutes to run, and a readiness check status expires after 5 hours.
Perform an OS reload for the bare metal server. Edit the selection and specify the version where the system reloads or upgrades.

Upgrading a High-Availabity vSRX deployment

The HA vSRX upgrade causes minimal downtime, limited to failover periods from primary to backup. Your previous configurations are automatically preserved and restored, but it's critical to keep offsite backups for added security. Plan 2 to 5 hours for each node upgrade, and set aside 8 to 10 hours to complete the entire cluster upgrade.

To upgrade an HA vSRX deployment, follow these steps:

Access the gateway details page.
Run a Readiness check for “Version upgrade” and address any errors that are found.

Run the readiness check several hours before the maintenance so that any outstanding access and configuration requirements are addressed before the upgrade maintenance. Readiness checks take about 30 minutes to run, and a readiness check status expires after 5 hours.
Perform an OS reload on each bare metal server one at a time, starting the next one only after the previous finishes. For each reload, manually select the OS version for installation or upgrade.

When you upgrade an HA cluster, the process automatically powers off the node not undergoing the OS reload at the end of the upgrade process. If you start the upgrade with the first node, the second node handles active network traffic during the reload. After the first node finishes reloading, the second node's VM is automatically powered off, and traffic shifts to the first node, which becomes the primary node with the new version. Leave the second node powered off at this stage. This action is intentional to prevent a version mismatch, where both nodes try to become primary causing an outage. After the first node's OS reload is complete and you confirm that traffic flows correctly, rerun the upgrade readiness check if needed, then proceed with the second node.

vSRX configuration migration considerations

For a High Availability environment, the upgrade restores the previous vSRX configuration. No further steps are needed.

For a stand-alone environment, the upgrade does not restore the previous configuration, so you must export and import your configuration. For more information, see Importing and exporting a vSRX configuration.

Also, when you migrate from an older version, such as 15.1, you might notice changes in interface mappings. This process requires some modifications to the vSRX configuration after the import. For more information, see Migrating 1G vSRX stand-alone configurations.