Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Junos OS Overview

 

Junos OS is the single operating system that powers Juniper’s broad portfolio of physical and virtual networking and security products.

Junos OS Overview

Juniper Networks provides high-performance network devices that create a responsive and trusted environment for accelerating the deployment of services and applications over a single network. The Junos® operating system (Junos OS) is the foundation of these high-performance networks.

Junos OS includes the following architecture variations:

  • Junos OS FreeBSD 6 on bare metal. This is Junos OS based on a FreeBSD 6 kernel.

  • Junos OS FreeBSD 10 on bare metal. This is Junos OS based on an upgraded FreeBSD kernel. Starting with Junos OS Release 15.1, certain hardware platforms run Junos OS with upgraded FreeBSD. Starting in Junos OS Release 16.1, Junos OS with upgraded FreeBSD can run as a guest virtual machine (VM) on a Linux VM host. For more on which platforms run Junos OS with upgraded FreeBSD, see Release Information for Junos OS with Upgraded FreeBSD.

  • Junos OS Evolved.

Unlike other complex, monolithic software architectures, Junos OS incorporates key design and developmental differences to deliver increased network availability, operational efficiency, and flexibility. The following are key advantages to this approach:

One Operating System

Unlike other network operating systems that share a common name but splinter into many different programs, Junos OS is a single, cohesive operating system that is shared across all network devices and product lines. This allows Juniper Networks engineers to develop software features once and share these features across all product lines simultaneously. Because features are common to a single source, they generally are implemented the same way for all product lines, thus reducing the training required to learn different tools and methods for each product. Because all Juniper Networks products use the same code base, interoperability between products is not an issue.

One Modular Software Architecture

Although individual modules of Junos OS communicate through well-defined interfaces, each module runs in its own protected memory space, preventing one module from disrupting another. This separation enables the independent restart of each module as necessary. This is in contrast to monolithic operating systems where a malfunction in one module can ripple to other modules and cause a full system crash or restart. This modular architecture then provides for high performance, high availability, security, and device scalability not found in other operating systems.

The Junos OS is preinstalled on your Juniper Networks device when you receive it from the factory. Thus, when you first power on the device, all software starts automatically. You simply need to configure the software so that the device can participate in the network.

You can upgrade the device software as new features are added or software problems are fixed. You normally obtain new software by downloading the software installation packages from the Juniper Networks Support Web page onto your device or onto another system on your local network. You then install the software upgrade onto the device.

Juniper Networks routing platforms run only binaries supplied by Juniper Networks, and currently do not support third-party binaries. Each Junos OS image includes a digitally signed manifest of executables that are registered with the system only if the signature can be validated. Junos OS will not execute any binary without a registered signature. This feature protects the system against unauthorized software and activity that might compromise the integrity of your device.

Secure Boot

Secure Boot is a significant system security enhancement based on the UEFI standard (see www.uefi.org). It works by safeguarding the BIOS itself from tampering or modification and then maintaining that protection throughout the boot process.

The Secure Boot process begins with Secure Flash, which ensures that unauthorized changes cannot be made to the firmware. Authorized releases of Junos OS carry a digital signature produced by either Juniper Networks directly or one of its authorized partners. At each point of the boot-up process, each component verifies the next link is sound by checking the signature to ensure that the binaries have not been modified. The boot process cannot continue unless the signature is correct. This "chain of trust" continues until the operating system takes control. In this way, overall system security is enhanced, increasing resistance to some firmware-based persistent threats.

Figure 1 shows a simplified version of this “chain of trust.”

Secure Boot requires no actions on your part to implement. It is implemented on supported hardware by default.

For information on which Junos OS releases and hardware support Secure Boot, see Feature Explorer and enter Secure Boot.

FIPS 140-2 Security Compliance

For advanced network security, a special version of Junos OS, called Junos-FIPS 140-2, is available. Junos-FIPS 140-2 provides customers with software tools to configure a network of Juniper Networks devices in a FIPS environment. FIPS support includes:

  • Upgrade package to convert Junos OS to Junos-FIPS 140-2

  • Revised installation and configuration procedures

  • Enforced security for remote access

  • FIPS user roles (Crypto Officer, User, and Maintenance)

  • FIPS-specific system logging and error messages

  • IPsec configuration for Routing Engine–to–Routing Engine communication

  • Enhanced password creation and encryption

Starting in Junos OS Release 15.1, Junos-FIPS is packaged in a domestic image only: a single Junos OS image supports both domestic and FIPS features. Users that have the FIPS credentials and permission to login can flip between a regular Junos image and FIPS image.

Note

Junos-FIPS has special password requirements. FIPS passwords must be between 10 and 20 characters in length. Passwords must use at least three of the five defined character sets (uppercase letters, lowercase letters, digits, punctuation marks, and other special characters). If Junos-FIPS is installed on the device, you cannot configure passwords unless they meet this standard.

Junos OS with Upgraded FreeBSD

Starting with Junos OS Release 15.1, certain hardware platforms run Junos OS based on an upgraded FreeBSD kernel instead of older versions of FreeBSD. Basing Junos OS on the newer kernel (referred to as Junos OS with upgraded FreeBSD) provides a clean-slate implementation of Junos OS on top of a pristine (minimally modified) and current version of FreeBSD. Another advantage of using the upgraded FreeBSD is access to sophisticated processing, efficiency, and security features which do not have to be reproduced in Junos OS.

Certain changes came with Junos OS with Upgraded FreeBSD: how Junos OS installation packages are named, some CLI commands and statements are deprecated and others are introduced, and how disk volumes and system backup (snapshots) work.

For more information on changes in Junos OS installation package names, see Junos OS Installation Package Names. For other changes in Junos OS with upgraded FreeBSD, see the following subsections:

Release Information for Junos OS with Upgraded FreeBSD

Junos OS with upgraded FreeBSD was first introduced in Junos OS Release 15.1 running on bare metal.

In Junos OS Release 16.1, with the release of virtualized Routing Engines RE-MX-X6, RE-MX-X8, and RE-PTX-X8, Junos OS with upgraded FreeBSD could run as a guest virtual machine (VM) on a Linux VM host.

Note

VM hosts only run virtualized Junos OS with upgraded FreeBSD.

Table 1: Upgrade Path to Junos OS with the Upgraded FreeBSD for SRX Series Devices

SRX Device

Release Supporting Junos OS with Upgraded FreeBSD

SRX5400

SRX5600

SRX5800

17.3R1

SRX1500

SRX4100

SRX4200

SRX4600

vSRX

17.4R1

To find which platforms support Junos OS with upgraded FreeBSD, see Feature Explorer and enter one of the following:

  • For non-virtualized, enter freebsd and select Junos kernel upgrade to FreeBSD 10+.

  • For virtualized, enter virtualization and select Virtualization of the Routing Engine.

Note

Before upgrading to Junos OS Release 15.1 or later on these platforms, see the installation and upgrade procedures in the following topics:

Processing Changes in Junos OS with Upgraded FreeBSD

The major processing changes in Junos OS with upgraded FreeBSD are as follow:

  • Interactions between Junos OS and the upgraded FreeBSD kernel use well-established interfaces because Junos OS is now layered on a minimally modified and current version of FreeBSD.

  • Symmetric multiprocessing (SMP) is enabled by default.

  • FreeBSD provides a consistent runtime environment for all Junos OS platforms.

  • An Upgraded FreeBSD image also includes FIPS mode as a configuration mode, eliminating the need for a separate FIPS package.

  • Better scaling numbers in platforms with multiple CPU cores.

  • No adverse effect on the routing engine performance on platforms with no additional virtual CPUs (VCPU).

  • Storage space for JUNOS root partition is 4 G and 16 G for var and config partitions, which is same as in the legacy JUNOS image.

Limitations:

The following limitations exist on the upgraded FreeBSD for SRX Series devices:

  • Upgraded FreeBSD is supported only on Routing Engine 1800X4 type.

  • The underlying FreeBSD is 64 bits, while there are specific 32-bit processes and utilities.

  • ISSU is not supported from an older version of FreeBSD to an upgraded FreeBSD. However, it is supported between upgraded FreeBSDs.

  • If you downgrade from Junos OS Release 17.4 to any previous releases, the system boots up with default factory configuration. Before attempting to downgrade from Junos OS Release 17.4 to any previous releases, the IDP configuration must be deleted.

There are also major changes in file structures and software packages. These changes are as follows:

  • New packages use XML description files instead of scripts.

  • Multiple package sets (a collection of installed packages) are stored on the device at the same time. Sets can be active (the currently used set), pending (the set that should be used at the next reboot), or previous (a formerly active set). Nonrecovery snapshots (but not recoverable image snapshots) are available for the package sets to preserve package content lists.

Changes in Package Names for Junos OS with Upgraded FreeBSD

Junos OS with upgraded FreeBSD is based on an upgraded FreeBSD kernel and has been released on a platform-by-platform basis starting in Junos OS Release 15.1. Package-naming conventions changed in certain ways with the release of Junos OS with upgraded FreeBSD, depending on the hardware platform.

Junos OS with upgraded FreeBSD packages use XML description files instead of scripts.

Installation package names for VM hosts begin with the junos-vmhost-install prefix.

For information on and examples of other installation package names for Junos OS with upgraded FreeBSD, see the following subsections:

Linux-Based Platforms Package Names

The following are components of the Junos OS with upgraded FreeBSD package-naming conventions for Linux-based packages such as those for SRX Series, ACX Series, NFX Series, OCX Series, and PTX Series:

  • Prefix—Linux-based devices use the jinstall-host prefix for Junos OS with upgraded FreeBSD.

  • Platform—This field indicates the major product group, such as acx, nfx, ocx, or ptx.

  • Product—This field indicates the specific product.

  • Architecture—This field indicates the CPU architecture of the platforms. Values include x86 for Intel and arm for Advanced RISC Machines CPUs.

  • Application Binary Interface (ABI)—This field indicates the “word length” of the CPU architecture. Values include 32 for 32-bit architectures and 64 for 64-bit architectures.

  • Release—This field indicates the release number, such as 17.3R1.3.

  • Edition—The edition field is null (empty) for standard (domestic) images. For jurisdictions with limits on dataplane encryption, this field is set to limited.

Examples of valid Junos OS with upgraded FreeBSD package names include the following:

  • jinstall-host-acx5k-17.2R1.13-signed.tgz

  • jinstall-host-nfx-2-flex-x86-32-17.2R1.13-secure-signed.tgz

EX Series Switches Package Names

There are multiple conventions for naming installation packages for EX Series switches.

  • The EX9200 switch is based on the MX Series routers and has the same package-naming convention as the MX Series routers. See MX Series Routers Package Names.

  • The EX4600 switch is based on the QFX5100 platform and has the same package-naming convention as the QFX5100 platform. See QFX Series and EX4600 Switches Package Names.

  • The components of the Junos OS with Upgraded FreeBSD package-naming conventions for EX2300 and EX3400 switches are as follows:

    • Prefix—This is junos-arm. This prefix takes the place of the jinstall prefix used in earlier releases of Junos OS.

    • Media keyword—Added to the prefix, a media keyword is only used when the image is not for use with the request system software add command. Media keywords follow the term media in the package name. Values for the media keyword include the following:

      • usb for images installed from a USB drive

      • net for images installed from the loader prompt

    • Architecture—This field indicates the CPU architecture of the platforms. Values include x86 for Intel and arm for Advanced RISC Machines CPUs.

    • Application Binary Interface (ABI)—This field indicates the “word length” of the CPU architecture. Values include 32 for 32-bit architectures and 64 for 64-bit architectures.

    • Release—This field indicates the release number, such as 15.1R1.9.

    • Edition—The edition field is null (empty) for standard (domestic) images. For jurisdictions with limits on dataplane encryption, this field is set to limited.

    As before, all images are in tarred and gzipped (.tgz) format.

    Note

    There are no longer “export” worldwide images or separate FIPS images. The keyword “signed” no longer appears because all Junos OS images are signed for validation.

Examples of valid Junos OS software package names include the following:

  • junos-arm-32-15.1X53-D50.2.tgz—Image for an EX2300 or EX3400 platform for jurisdictions without limits on dataplane encryption.

  • junos-arm-32-15.1X53-D50.2-limited.tgz —Image for an EX2300 or EX3400 platform for jurisdictions with limits on dataplane encryption.

  • junos-install-media-usb-arm-32-15.1X53-D50.2.img—Image stored on and installed from a USB drive for a EX2300 or EX3400 platform for jurisdictions without limits on dataplane encryption.

  • junos-install-media-net-arm-32-15.1X53-D50.2.tgz—Image stored on the tftp server and installed from a loader prompt for a EX2300 or EX3400 platform for jurisdictions without limits on dataplane encryption.

MX Series Routers Package Names

The components of the Junos OS with Upgraded FreeBSD package-naming conventions for MX Series routers and EX9200 switches are as follows:

  • Prefix—This is junos-install. This prefix takes the place of the jinstall prefix used in earlier releases of Junos OS.

  • Media keyword—Added to the prefix, a media keyword is only used when the image is not for use with the request system software add command. Media keywords follow the term media in the package name. Values for the media keyword include the following:

    • usb for images installed from a USB drive

    • net for images installed from the loader prompt

  • Platform—This field indicates the major product group, such as ex92xx or mx.

  • Architecture—This field indicates the CPU architecture of the platforms. Values include x86 for Intel and arm for Advanced RISC Machines CPUs.

  • Application Binary Interface (ABI)—This field indicates the “word length” of the CPU architecture. Values include 32 for 32-bit architectures and 64 for 64-bit architectures.

  • Release—This field indicates the release number, such as 17.3R1.3.

  • Edition—The edition field is null (empty) for standard (domestic) images. For jurisdictions with limits on dataplane encryption, this field is set to limited.

As before, all images are in tarred and gzipped (.tgz) format.

Note

There are no longer “export” worldwide images or separate FIPS images. The keyword “signed” no longer appears because all Junos OS images are signed for validation.

Examples of valid Junos OS with upgraded FreeBSD package names include the following:

  • junos-install-mx-x86-32-15.1R1.9.tgz—Image for a supported MX Series platform for jurisdictions without limits on dataplane encryption.

  • junos-install-mx-x86-32-15.1R1.9-limited.tgz—Image for a supported MX Series platform used for jurisdictions with limits on dataplane encryption.

  • junos-install-media-usb-mx-x86-32-15.1R1.9.tgz—Image stored on and installed from a USB drive for a supported MX Series platform for jurisdictions without limits on dataplane encryption.

  • junos-install-ex92xx-x86-64-17.2R1.13-limited.tgz—Image for an EX9200 plaform for jurisdictions with limits on dataplane encryption.

  • junos-install-media-usb-ex92xx-17.2R1.13.img.gz—Image stored on and installed from a USB for an EX9200 platform for jurisdictions without limits on dataplace encryption.

QFX Series and EX4600 Switches Package Names

The components of the Junos OS with upgraded FreeBSD package-naming conventions for QFX Series and EX4600 switches installation packages are as follows:

  • Prefix—Linux-based devices use the jinstall-host prefix for Junos OS with upgraded FreeBSD.

  • Platform—This field indicates the major product group, such as ex-4600 or qfx.

  • Product—This field indicates the specific product, such as 5e or 10-f or 10-m

  • Architecture—This field indicates the CPU architecture of the platforms. Values include x86 for Intel and arm for Advanced RISC Machines CPUs.

  • Application Binary Interface (ABI)—This field indicates the “word length” of the CPU architecture. Values include 32 for 32-bit architectures and 64 for 64-bit architectures.

  • Release—This field indicates the release number, such as 17.3R1.3.

  • Edition—The edition field is null (empty) for standard (domestic) images. For jurisdictions with limits on dataplane encryption, this field is set to limited.

Examples of valid Junos OS with upgraded FreeBSD package names include the following:

  • jinstall-host-ex-4600-17.2R1.13-limited-signed.tgz

  • jinstall-host-ex-4600-17.2R1.13-signed.tgz

  • jinstall-host-qfx-5e-x86-64-17.2R1.13.tgz

  • jinstall-host-qfx-10-f-flex-x86-64-17.2R1.13-secure-signed.tgz

  • jinstall-host-qfx-10-m-x86-64-17.2R1.13-secure-limited-signed.tgz

  • jinstall-host-qfx-5-17.2R1.13-limited-signed.tgz

SRX5400, SRX5600, and SRX5800 Devices Package Names

The components of the Junos OS with upgraded FreeBSD package-naming conventions for SRX5400, SRX5600, and SRX5800 are as follows:

  • Prefix—This is junos-install. This prefix takes the place of the prefix junos-srx5000.

  • Media keyword—Added to the prefix, a media keyword is only used when the image is not for use with the request system software add command. Values for the media keyword include usb for images installed from a USB drive or net for images installed from the loader prompt; for example, the entire prefix of your package might be junos-install-media-net or junos-install-media-usb.

  • Architecture—This field indicates the CPU architecture of the platforms. Values include x86 for Intel and arm for Advanced RISC Machines CPUs.

  • Application binary interface (ABI)—This field indicates the “word length” of the CPU architecture. Values include 32 for 32-bit architectures and 64 for 64-bit architectures.

  • Release—This field indicates the release number, such as 17.3.

  • Edition—The edition field is null (empty) for the standard (domestic) images. For jurisdictions with limits on dataplane encryption, this field is set to limited.

Note

There are no longer “export” worldwide images or separate FIPS images. The keyword “signed” no longer appears because all Junos OS images are signed for validation.

Examples of valid Junos OS software package names include the following:

  • junos-install-srx5000-x86-64-17.3R1.9.tgz—An image for a SRX5400, SRX5600, and SRX5800 devices.

  • junos-install-media-usb-srx5000-x86-64-17.3R1.9.img.gz—An image stored on and installed from a USB flash drive for SRX5400, SRX5600, and SRX5800 devices.

Changes in Commands and Statements in Junos OS with Upgraded FreeBSD

There is now a separate Operation, Administration, and Maintenance (OAM) volume (oam) distinct from the Junos OS volume (junos).

One major change between Junos OS and Junos OS with upgraded FreeBSD is the distinction between recovery snapshots and nonrecovery snapshots.

The upgraded FreeBSD kernel requires changes to several commands and statements and their related parameters. The new and changed actions are summarized in Table 2. For details on the changes listed in Table 2, see the topics covering the specific command or statement.

For changed actions for VM hosts, see VM Host Operations and Management.

Table 2: New and Changed Commands and Statements for Junos OS with Upgraded FreeBSD

Command or Statement

Change

request system snapshot delete snapshot

New action

request system snapshot recovery

New action

request system snapshot load snapshot

New action

request system recover volume

New action: volume is either /junos-volume or /oam-volume

request system snapshot

Changed action

show system snapshot

Changed action

request system reboot (junos | network | oam | usb}

Changed action with new media options

request system reboot

Changed action

request system software validate on

Changed action

request system software rollback

Changed action

The upgraded FreeBSD kernel also requires that several commands and statements in Junos OS be deprecated in Junos OS with upgraded FreeBSD. The deprecated commands and statements are summarized in Table 3. The date of deprecation is the release date for that platform supporting Junos OS with upgraded FreeBSD. To find which platforms support Junos OS with upgraded FreeBSD, see Feature Explorer and enter one of the following:

  • For non-virtualized, enter freebsd and select Junos kernel upgrade to FreeBSD 10+.

  • For virtualized, enter virtualization and select Virtualization of the Routing Engine.

Table 3: Deprecated Commands and Statements for Junos OS with Upgraded FreeBSD

Deprecated Command or Configuration Statement

Release Deprecated

Deprecated Command

request system partition abort

see Feature Explorer.

request system partition compact-flash

request system partition hard-disk

request system snapshot <config-partition>

request system snapshot <root-partition>

request system snapshot <slice>

request system software delete-backup

request system software rollback <force>

show system processes providers

show system snapshot <slice>

Deprecated Configuration Statement

set system mirror-flash-on-disk

see Feature Explorer.

Changes in Disk Volumes for Junos OS with Upgraded FreeBSD

In computer data storage, a volume or logical drive is a single accessible storage area with a single file system, typically (though not necessarily) resident on a single partition of a hard disk.

Junos OS with upgraded FreeBSD has two volumes: dev/gpt/junos (/junos for short) and a separate operations, administration, and maintenance (OAM) volume dev/gpt/oam (/oam for short).

/junos Volume

The /junos volume is used for running device software and holds configuration information and logs.

The /junos volume contains a directory named /packages/db that has all the components present on the device, such as os-kernel-123, os-kernel-456, and so on. A sibling directory named /package-sets is also present. Package sets are an important concept in Junos OS with upgraded FreeBSD.

The /package-sets directory contains a package listing that gathers all the components of the running Junos OS into an XML format in the /active subdirectory. So os-kernel-123 could be a component in the /package-sets/active subdirectory, but then os-kernel-456 could not be in the same XML package. Package sets do not contain the kernel software itself (for example), but tell the device where to find the kernel component needed for the software package. The same kernel can be present in several package listings, but only one package can be active and running on the device at any given time.

There are several directories on the /junos volume where a particular software package listing can be found:

  • /previous— The package set in this directory contains the list of all the components that ran on the device before the last upgrade.

  • /active— The package set in this directory contains the list of all the software components currently running on the device.

  • /pending— The package set in this directory contains the list of all the software components on the device that will run after the next reboot.

Note

After a successful reboot, the package set in the /pending directory becomes the active package set, and the package set in the /active directory becomes the previous set.

The /junos volume also contains non-recovery snapshots taken with the request system snapshot command. These types of snapshots are new to Junos OS with upgraded FreeBSD and cannot be used for recovery of a failed system. Non-recovery snapshots are a special type of package set that includes a copy of the configuration. For more information on non-recovery snapshots, see Changes in Use of Snapshots for Junos OS with Upgraded FreeBSD.

/oam Volume

The compact flash drive is the /oam volume. In case of failure of the main drive (that is, the /junos volume), the /oam volume can be used to boot the system. In order to perform this reboot, the /oam volume needs to have all of the information required to provide the system with a running configuration. This information is provided by the recovery snapshot, created with the request system snapshot recovery command. Although it can take a while to perform, the recovery snapshot establishes an .izo or .iso image of the running Junos OS. For more information on recovery snapshots, see Changes in Use of Snapshots for Junos OS with Upgraded FreeBSD.

Changes in Use of Snapshots for Junos OS with Upgraded FreeBSD

Snapshots taken with Junos OS with upgraded FreeBSD are not the same as snapshots taken with Junos OS (as in legacy Junos OS). The two are not compatible with each other. A recovery snapshot on a USB taken from a router running Junos OS based on the older FreeBSD kernel is not supported for recovery after the router is upgraded to Junos OS with upgraded FreeBSD.

Junos OS with upgraded FreeBSD has two types of snapshots: recovery snapshots (which are not the same thing as recovery snapshots taken using the older Junos OS) and non-recovery snapshots. Recovery snapshots and non-recovery snapshots have different content, locations, and purposes, so it is important that they are created and maintained properly. We recommend that you generate both a non-recovery and a recovery snapshot after you successfully upgrade to Junos OS with upgraded FreeBSD, and refresh these snapshots periodically.

Recovery Snapshots

The major characteristics of recovery snapshots are as follow:

  • Recovery snapshots are full copies of the packages and configuration taken at the time the snapshot command is issued.

  • Recovery snapshots reside on the OAM volume or USB medium.

Recovery snapshots take some time to complete because of the level of detail captured. Recovery snapshots can be used to recover the Junos OS volume. There is only ever one recovery snapshot on the system.

A recovery snapshot is automatically taken when, for the first time, you upgrade from a pre-FreeBSD-based Junos OS release to Junos OS with upgraded FreeBSD. Therefore, unless someone manually deletes the recovery snapshot, there should always be a recovery snapshot.

If a device does not have a recovery snapshot, then the only way to recover the device would be to do a media install (network or USB).

Helpful commands for recovery snapshots are:

  • request system snapshot recovery—Use this command to create a recovery snapshot. You can use other parameters to determine the details of the recovery snapshot created. There is only ever one recovery snapshot on the system.

  • show system snapshot—As of Junos OS Release 17.2, use this command to list the recovery snapshot.

  • Previous to Junos OS Release 17.2, use the following shell command to see if a recovery snapshot exits on the device:

Non-Recovery Snapshots

The major characteristics of the non-recovery snapshots are as follows:

  • Non-recovery snapshots reside on the /junos volume.

  • Non-recovery snapshots refer to the current running set of packages and a copy of the configuration at the time the snapshot command is issued.

  • Non-recovery snapshots do not need to copy the whole Junos OS installation and so are very fast.

  • Non-recovery snapshots can be requested as the boot image for the next reboot.

  • There can be many non-recovery snapshots on the device, and the files can be renamed.

Multiple non-recovery snapshots, essentially lists of software components and configuration files, can be helpful when major software or configuration changes are occurring and establishment of a known stable system baseline is required.

Non-recovery snapshots consume little space, except for the config.tgz file.

A non-recovery snapshot is also a package set in a sense, with the addition of a copy of the configuration at the time that the non-recovery snapshot is taken.

Packages that are no longer referenced by any package set or non-recovery snapshot are automatically deleted. We recommend deleting any old non-recovery snapshots after an upgrade so that old packages can be deleted and space recovered.

The snapshot script (which is the script that generates output for non-recovery snapshots) does not generate XML output. In such cases, the <output> tag is used.

user@host> request system snapshot | display xml

This is documented in <rpc-reply> in the Junos XML Management Protocol Developer Guide.

Some helpful commands for non-recovery snapshots are:

  • request system snapshot—Use this command to create a non-recovery snapshot.

  • show system snapshot—Use this command to list all the available non-recovery snapshots.

  • request system snapshot delete—Use this command to delete a non-recovery snapshot.