Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Software Installation and Upgrade Overview (Junos OS Evolved)

SUMMARY A Juniper Networks device is delivered with the Juniper Networks operating system (Junos OS Evolved) already installed. When you power on the device, it starts (boots) using the installed software. As new features and software fixes become available, you must upgrade your software to use them.

Before installing software, you must back up the system, including the configuration. You upgrade (or downgrade) the version of the operating system on a device by copying a software installation package to your device and then use the CLI to install the new software on the device. You then reboot the device, which boots from the newly installed software. After a successful upgrade, back up the new software and configuration. See Back Up and Recover Software with Snapshots.

Note:

Before installing software on a device that has one or more custom YANG data models added to it, back up and remove the configuration data corresponding to the custom YANG data models from the active configuration. For more information see Managing YANG Packages and Configurations During a Software Upgrade or Downgrade.

To understand more about Junos OS Evolved Software Licensing, see the Juniper Licensing Guide. Please refer to the product Data Sheets accessible from Products & Services for details, or contact your Juniper Account Team or Juniper Partner.

The following sections introduce the overall considerations in upgrading and downgrading the software:

Types of Junos OS Evolved Installation

The two types of installations used to upgrade or downgrade your device are standard installation and recovery. The standard installation is the standard method of upgrading and downgrading the software. You perform a recovery installation when the software on the device is damaged or otherwise unable to accommodate a software upgrade or downgrade.

Standard Installation

A standard installation is the typical method used to upgrade or downgrade software on the server. This method uses the installation package that matches the installation package already installed on the system. For information on the different installation packages available, see Junos OS Evolved Installation Packages.

Recovery Installation

A recovery installation is the method used to repair a device with damaged software or a condition that prevents the upgrade or downgrade of the software.

Multiple Software Versions Available

Junos OS Evolved stores multiple versions of software on the storage media. To see the software packages installed on the system, use the show system software list operational mode command. Junos OS Evolved also allows you to roll back to any of the releases already stored on the system with the request system software rollback operational mode command.

Each version also stores the last configuration file that was running when that release was running. Junos OS Evolved supports a roll back to an alternate image with either the current configuration file or with the configuration snapshot from when the alternate image was last running, using the request system software rollback image-name with-old-snapshot-config operational mode command.

Node Software Synchronization for Dual-Routing Engine Systems

Junos OS Evolved ensures all nodes in a system are running the same software version.

If you insert a Routing Engine that has the same current software version as the primary Routing Engine into the system, the new Routing Engine joins the system. The system automatically synchronizes the configurations and the other software versions from the existing Routing Engine to the new Routing Engine, even if you have not configured theauto-sw-sync statement.

If you insert a Routing Engine that has a different software version into the system, the Routing Engine is kept outside the system and the system generates a software mismatch alarm. The alarm specifies the Routing Engine name and the version of software on the newly-inserted Routing Engine, similar to the following: Software Version Mismatch on re1:junos-evo-install-ptx-x86-64-20.4R2.6-EVO. You need to manually synchronize the Routing Engines to bring RE1 back into the system.

You can either manually or automatically synchronize the software versions and configurations to the new Routing Engine. Automatic software synchronization is disabled by default. We recommend that you enable automatic software synchronization.

  • To automatically always synchronize the software versions and configurations to the new Routing Engine, configure the auto-sw-sync enable statement at the [edit system] hierarchy level. When you configure the auto-sw-sync statement, the system detects the new Routing Engine, synchronizes all of the images to the new Routing Engine, and reboots the new Routing Engine so that the new Routing Engine boots up with the same software and the same configuration version as the primary Routing Engine and joins the system. Each software image contains the configuration running when that software image was last active.

  • To manually synchronize the software versions and configurations to the new Routing Engine, use the request system software sync all-versions operational mode command. All software images and configurations stored with the images are synchronized to the new Routing Engine and the system reboots the new Routing Engine. When the new Routing Engine comes back up, the new Routing Engine joins the system.

For a dual-Routing Engine system, when the secondary Routing Engine boots with a different current image than the primary Routing Engine's current image and you have configured the auto-sw-sync enable statement, the primary Routing Engine synchronizes the current image to the secondary Routing Engine. The primary Routing Engine also synchronizes the rollback software image and the other images to the secondary Routing Engine. If the current configuration file (juniper.conf.gz) from the primary Routing Engine matches the current configuration file on the secondary Routing Engine, then the primary Routing Engine does not synchronize the rescue configuration (rescue.conf.gz) to the secondary Routing Engine.

To synchronize the rescue configuration from the primary Routing Engine to the secondary Routing Engine, issue the file copy command on the primary Routing Engine:

For more information on replacing Routing Engines, see Replace a Routing Engine in a Dual-Routing Engine System.

Migrate to GPT Disk Partitioning

Starting in Junos OS Evolved Release 24.2R1, we support migrating to GUID Partition Table (GPT) disk partitioning. GPT is the native disk partitioning scheme used by UEFI BIOSes. GPT is similar to the Master Boot Record (MBR) disk partitioning scheme used by traditional BIOSes. All Junos OS Evolved platforms support GPT natively. However, we default to MBR disk partitioning because Junos OS Evolved was originally ported to systems that used traditional BIOSes.

GPT has several advantages over MBR:

  • Support for much larger disks

  • Unique partition ID support by using GUIDs

  • Human-readable partition names

  • Backup copies

When you install a release that supports GPT disk partitioning, you can:

  • For new installations, change the default partition scheme for both the primary and secondary disks to GPT immediately (for example, scratch installations to empty disks).

  • For existing installations, migrate to GPT disk partitioning for both the primary and secondary disks after a reboot of the system.

If a hard disk is currently using GPT disk partitioning and you roll back the software to a release that does not support GPT disk partitioning as the default, the hard disk continues to use GPT disk partitioning. That is, once you migrate a disk to GPT disk partitioning, it continues to use GPT disk partitioning, even if you install older software and reboot the system.

For dual Routing-Engine systems:

  • If Routing Engine 0 is running a release that supports GPT disk partitioning by default and a new Routing Engine 1 is inserted, the primary and secondary disks for Routing Engine 1 migrate to the GPT disk partitioning scheme upon reboot of Routing Engine 1.

  • If the auto-sw-sync enable configuration statement is not configured on Routing Engine 0, then even through Routing Engine 0 is running a release that supports GPT disk partitioning by default, the primary and secondary disks for Routing Engine 1 do not migrate to the GPT disk partitioning scheme upon reboot of Routing Engine 1. To migrate to the GPT disk partitioning scheme, after you upgrade the software, you must manually synchronize the Routing Engines by issuing the request system software sync all-versions command on Routing Engine 0, and then reboot Routing Engine 1.

If you are using the gNOI software upgrade mechanism, neither staging nor activating a release image changes the partition scheme of the disks. (Currently, you can choose to activate an image but not reboot. You also can delete that activated image before rebooting the system.) Once you reboot the system with the activated image, then the primary and secondary disks migrate to the GPT disk partition scheme.

For systems that support ISSU, you must reboot the system to migrate the primary and secondary disks to the GPT disk partitioning scheme. Simply restarting applications to complete the upgrade does not migrate the disks to the GPT disk partitioning scheme.

Back up the Current System’s Files

Creating a backup of the current system on your device has the following advantages:

  • The device can boot from a backup and come back online in case a component fails or a power failure during an upgrade corrupts the primary boot device.

  • The backup copy of the system saves your active configuration files and log files.

  • The device can recover from a known, stable environment in case of an unsuccessful upgrade.

During a successful upgrade, the upgrade package completely re-installs the existing operating system. It retains the juniper.conf, rescue.conf, SNMP ifIndexes, /var/home, /config/scripts, SSH files, and other filesystem files. The upgrade process removes all other information. Therefore, you should back up your existing system in case you need to return to it after running the installation program.

You create copies of both the software and the configuration running on a device using the request system snapshot command. The request system snapshot command takes a “snapshot” of the files currently used to run the device and copies the files onto the alternate solid-state drive (SSD). The snapshot contains the complete contents of the /soft, /config, and /root directories, which include the current and all rollback software images, copies of user data, the active configuration, the rescue configuration, and content from the /var directory (except the /var/core, /var/external, /var/log, and /var/tmp directories).

You can then use this snapshot to boot the device at the next boot up or as a backup boot option. When the backup completes, the current and backup software installations are identical. For a dual-Routing Engine system, you should create a snapshot on both the primary and the secondary Routing Engine, ensuring a snapshot is available, no matter which Routing Engine you use to reboot the device.

Note:

When you issue the request system snapshot command, the system backs up the /root file system and the /config file system to the secondary solid-state drive (SSD). The /root and /config file systems are on the device's primary SSD. The snapshot /root and /config file systems are on the device's secondary SSD.

Determine the Software Installation Package

Juniper Networks delivers software releases in signed packages that contain digital signatures to ensure official Juniper Networks software. To see the information about the software packages currently running on the device, use the show version operational mode command at the top level of the command-line interface (CLI).

Note:

The show version command does not show the software edition, only the release number of the software.

You download software to the /var/tmp directory of your device from the Juniper Networks Software Downloads webpage.

For more information about software packages, see Junos OS Evolved Installation Packages.

Connect to the Console

We recommend that you upgrade all individual software packages using an out-of-band connection from the console or the management Ethernet interface, because in-band connections can drop during the upgrade process.

Console ports allow root access to devices through a terminal or laptop interface, regardless of the state of the device, unless the device is off. By connecting to the console port, you can access the root level of the device, without using the network to which the device might or might not be connected. Connecting to the console port creates a secondary path to the device without relying on the network.

Using the terminal interface provides a technician, who is usually sitting in a NOC a long distance away, the ability to restore a device or perform an initialization configuration securely, using a modem, even if the primary network has failed. Without a connection to the console port, a technician must visit the site to perform repairs or initialization. A remote connection to the device through a modem requires the cable and connector (provided in the device accessory box), plus a DB-9 to DB-25 (or similar) adapter for your modem, which you must purchase separately. For more information about connecting to the console port, see the hardware guide for your particular device.

Validate the Installation Package with the Current Configuration

When you upgrade or downgrade software, we recommend that you validate the configuration with the request system software add operational mode command, to check that the candidate software is compatible with the current configuration. By default, when you add a package with a different release number, the system automatically performs the validation check.

Upgrade Method Impacts on Internal Media

Installation from the boot loader using a USB storage device re-formats the internal media before installation.

Installation using the CLI retains the existing partitioning scheme.

CAUTION:

Upgrade methods that re-format the internal media before installation wipe out the existing contents of the media and the configuration files. You must back up all configuration files in the /config directory and any important data before starting the installation process.

Boot Sequence

Juniper Networks devices start using the installed Junos OS Evolved software. Boot-able copies of the software are stored in two locations: the internal solid-state drive and the removable media (USB). The following subsections discuss the order of the locations the system checks for a valid boot-able operating system.

Boot Order

Junos OS Evolved devices attempt to boot from these storage media in the following order:

  1. Dual, internal SSD devices. First, the system tries to boot from the primary SSD device. If that SSD fails to boot, then the system attempts to boot from the secondary SSD device.

  2. USB device. (If you insert a USB emergency boot device, select USB00 from the GRUB menu to boot from the USB device.)

Boot from an Alternate Boot Device

If the device boots from an alternate boot device, when you log in to the device, a message displays indicating the alternate boot device. For example, the following message shows that the software booted from the secondary SSD (/dev/sdb):

Note:

Do not select an emergency boot device during reboot under normal operations. The router does not operate normally when booted from an emergency boot device. Selecting the USB00 option on the GRUB menu installs the image from the USB onto the SSD. You must then apply the user configuration.

The system boots from an alternate boot device when the system detects a problem with the primary boot device—usually the primary SSD (/dev/sda)—that prevents the device from booting. Consequently, the system boots from the alternate boot device (the secondary SSD, /dev/sdb). When the system boots from the alternate boot device, the system removes the primary boot device from the list of candidate boot devices. The problem is usually a serious hardware error. We recommend you contact the Juniper Networks Technical Assistance Center (JTAC).

When the device boots from the alternate boot device, the software and the configuration are only as current as the most recent snapshot (taken with the request system snapshot operational mode command).