Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Managing Configurations

The show | compare | display xml Command Output

The compare | display xml filter compares the candidate configuration with the current committed configuration and displays the differences between the two configurations in XML. To compare configurations, enter compare | display xml after the pipe ( | ) symbol in either operational or configuration mode.

Example in operational mode:

Example in configuration mode:

You can enter a specific configuration hierarchy immediately preceding the compare filter, for example, show configuration system syslog | compare | display xml. In configuration mode, you can navigate to a hierarchy where the command is applied.

The differences from the compare filter function are output in XML. The configuration tag starts the output. The context for changes is established with hierarchy name tags relative to the root of the compare. For element changes, an operation attribute is output in the tag where a change occurs. This attribute has the value create, delete, or merge. For metadata changes, the metadata name is specified. For example, if a statement is marked inactive, the inactive="inactive" attribute and value are output. The nc namespace is used when necessary to indicate that an attribute is in the NETCONF namespace rather than the operating system namespace.

Note:

Beginning with Junos OS Release 16.2R2, the show | compare | display xml command omits the <configuration> tag in the XML output if the comparison returns no differences or if the comparison returns only differences for non-native configuration data, for example, configuration data associated with an OpenConfig data model.

The following sections explain the XML that is generated for specific types of configuration changes. The corresponding text changes are shown for comparison.

Add a Statement (create Operation)

The following example shows the addition of IPv4 address 2.2.2.2 to unit 1.

The tags through name provide the context for the addition. The operation="create" attribute indicates that a unit statement was created and is defined by the configuration within the unit tag.

Delete a Statement (delete Operation)

The following example shows the deletion of a simple statement in the configuration hierarchy. The tags through system provide the context for the deletion. The operation="delete" attribute indicates that the services statement was deleted. The configuration following the services statement was deleted though is not output.

The following example shows the deletion of unit 1 from the ge-0/0/0 interface. The configuration following the unit statement was deleted though is not output.

The following example shows the deletion of the apply-groups configuration. The groups that are deleted are not shown in the output.

Change a Statement (delete and create Operations)

The following example shows a change in a statement in the hierarchy. The tags through system provide the context for the change. The operation="delete" attribute indicates that the host-name statement was deleted. The configuration following the host-name statement was deleted, but this is not shown in the output. The operation="create" attribute indicates that a host-name statement was created and is defined by the configuration within the host-name tag.

Change Metadata (inactive Attribute and Operation)

The following example shows the inactivation of a statement in the hierarchy. The tags through system provide the context for the change. The inactive="inactive" attribute indicates that the syslog statement was inactivated.

The following example shows the addition of an inactive syslog statement. The operation="create" attribute indicates that the syslog statement was created and is defined by the configuration within the syslog tag. The inactive="inactive" attribute indicates that the syslog statement was inactivated.

Add an Annotation (comment Tag and create Operation)

The following example shows the addition of a comment to a statement. The tags through syslog provide the context for the annotation. The operation="create" attribute for the junos:comment tag indicates that a comment was added to the [edit system syslog] hierarchy.

The following example shows the addition of a comment to a statement. The tags through syslog provide the context for the annotation. The operation="create" attribute for the junos:comment tag indicates that a comment was added to the [edit system syslog] hierarchy for the statement output within the syslog tag.

Change an Annotation (comment Tag, and delete and create Operations)

The following example shows the change of a comment for a statement. The tags through system provide the context for the annotation.

  • The operation="delete" attribute for the junos:comment tag indicates that a comment was deleted from the [edit system] hierarchy at the syslog statement.

  • The operation="create" attribute for the junos:comment tag indicates that a comment was added to the [edit system] hierarchy for the syslog statement.

Add a Statement Inside a Container (create Operation, and insert and key Attributes)

The following example shows the addition of a file statement at the [edit system syslog] hierarchy. The tags through syslog provide the context for the addition.

  • The operation="create" attribute for the file tag indicates that a file statement was added.

  • The yang:insert="after" attribute indicates that the file was added after the position indicated by the yang:key="[name='file-1']" attribute.

  • The file-1 value represents the position within the existing file statements, where one is the first file.

  • In this example, the new file statement was added after the first file.

Change the Order Inside a Container (merge Operation, and insert and key Attributes)

The following example shows the change in order of file statements at the [edit system syslog] hierarchy. The tags through syslog provide the context for the change.

  • The operation="merge" attribute for the file tag indicates that an existing file statement was moved.

  • The yang:insert="after" attribute indicates that the file was moved after the file in the position indicated by the yang:key="[name='file-1']" attribute.

  • The file-1 value represents a position within the existing file statements, where one is the first file.

  • The value at the name tag, file-3, represents a position within the existing file statements.

  • In this example, the file statement in the third position was moved after the first file.

Returning to the Most Recently Committed Configuration

To return to the most recently committed configuration and load it into configuration mode without activating it, use the rollback configuration mode command:

To activate the configuration to which you rolled back, use the commit command:

Returning to a Previously Committed Configuration

This topic explains how you can return to an earlier configuration than the most recently committed one.

Example of Returning to a Previous Configuration

To return to a previous configuration, you include the configuration number, 0 through 49, in the rollback command. The most recently saved configuration is number 0 (which is the default configuration to which the system returns), and the oldest saved configuration is number 49.

Example:

Example of Displaying Previous Configurations

To display previous configurations, you use the rollback ? command. You include the rollback number, date, time, the name of the user who committed changes, and the method of commit.

Example:

About Comparing Configuration Versions

In configuration mode only, when you have made changes to the configuration, you can compare the candidate configuration with a prior version. To compare versions, you use the compare command to display the configurations. The compare command compares the candidate configuration with either the current committed configuration or a configuration file. This command also displays the differences between the two configurations.

To compare configurations, you specify the compare command after the pipe:

  • filename is the full path to a configuration file. The file must be in the proper format: a hierarchy of statements.

  • n is the index into the list of previously committed configurations. The most recently saved configuration is number 0, and the oldest saved configuration is number 49. If you do not specify arguments, the system compares candidate configuration against the active configuration file (/config/juniper.conf).

The comparison output includes the following symbols in the prefix for statements that are:

  • In the candidate configuration only: a plus sign (+).

  • In the comparison file only: a minus sign (-).

  • Unchanged; a single blank space ( ).

The following example shows various changes, followed by a comparison of the candidate configuration with the active configuration. The example shows only the changes made at the [edit protocols bgp] hierarchy level:

Using Configuration Revision Identifiers

Every commit has a configuration revision identifier (CRI) associated with it. The CRI is a unique string that, unlike the rollback index, does not change when new configurations are committed.

Because the CRI for a given committed configuration is fixed, it has advantages over using a rollback index. Network management systems (NMS) can cache the CRI for a given commit. At a later date, the NMS can compare the cached value to the CRI of the current configuration on the network device to detect if other systems made out-of-band configuration changes to the device, for example, during a maintenance window.

Additionally, starting in Junos OS and Junos OS Evolved Release 20.4R1, you can use the CRI associated with a committed configuration to:

  • View the configuration.

  • Compare two configurations.

  • Revert to the configuration.

  • Retrieve the current rollback index associated with that configuration.

To view the CRI associated with each commit, use the show system commit include-configuration-revision command. This will display the system commit history and the CRI for each commit.

Alternatively, you can view the CRI for a specific rollback number by issuing the show system rollback number configuration-revision command.

Once you have the CRI string for a specific commit, you can view that configuration with the show system configuration revision cri-string command.

You can compare 2 configurations by using the compare option with both CRIs.

You can also use view the rollback number for a specific CRI by including the rollback-number cri-string option.

Additionally, in configuration mode, you can roll back to a configuration by specifying the CRI instead of the rollback index.

Saving a Configuration to a File

Saving a device configuration to a file allows you to edit it with any plain text editor of your choice. You can save your current configuration to an ASCII file, which saves the configuration in its current form, including any uncommitted changes. If more than one user is modifying the configuration, all changes made by all users are saved.

To save software configuration changes to an ASCII file, use the save configuration mode command:

The contents of the current level of the statement hierarchy (and below) are saved, along with the statement hierarchy containing it. This allows a section of the configuration to be saved, while fully specifying the statement hierarchy.

By default, the configuration is saved to a file in your home directory, which is on the flash drive.

When you issue this command from anywhere in the hierarchy (except the top level), a replace tag is automatically included at the beginning of the file. You can use the replace tag to control how a configuration is loaded from a file.

Example:

About Compressing the Current Configuration File

By default, the current operational configuration file is compressed and is stored in the file juniper.conf.gz in the /config file system. The operational configuration file is stored along with the last three committed versions of the configuration. If you have large networks, the current configuration file might exceed the available space in the /config file system. Compressing the current configuration file enables the file to fit in the file system, typically reducing the size of the file by 90 percent. You might want to compress your current operational configuration files when they reach 3 megabytes (MB) in size.

When you compress the current configuration file, the names of the configuration files change. To determine the size of the files in the /config file system, you issue the file list /config detail command.

Note:

We recommend that you compress the configuration files (this is the default) to minimize the amount of disk space that they require.

  • If you want to compress the current configuration file, include the compress-configuration-files statement at the [edit system] hierarchy level:

  • Commit the current configuration file to include the compression-configuration-files statement. Commit the configuration again to compress the current configuration file:

  • If you do not want to compress the current operational configuration file, include the no-compress-configuration-files statement at the [edit system] hierarchy level:

  • Commit the current configuration file to include the no-compress-configuration-files statement. Commit the configuration again to uncompress the current configuration file:

Free Up System Storage Space

Problem

Description

The system file storage space on the device is full. Rebooting the switch does not solve the problem.

The following error message appears during a typical operation on the device after the file storage space is full:

Solution

Clean up the file storage on the device by deleting system files.

  1. Issue a request to clean up (delete) system files.

    The list of files to be deleted is displayed.

  2. Select yes to delete the files.

  3. Reboot the device.

Best Practice: Best Practice

We recommend that you regularly issue a request to clean up the system file storage. Cleaning up the system file storage space optimizes device performance.

Clean Up Files with the CLI

You can use the CLI request system storage cleanup command to rotate log files and delete unnecessary files on the device. If you are running low on storage space, the file cleanup procedure quickly identifies files that you can delete.

The file cleanup procedure performs the following tasks:

  • Rotates log files—Archives all information in the current log files, deletes old archives, and creates fresh log files.

  • Deletes log files in /var/log—Deletes any files that are not currently being written to.

  • Deletes temporary files in /var/tmp—Deletes any files that have not been accessed within two days.

  • Deletes all crash files in /var/crash—Deletes any core files that the device has written during an error.

  • Deletes all software images (*.tgz files) in /var/sw/pkg—Deletes any software images copied to this directory during software upgrades.

To rotate log files and delete unnecessary files with the CLI:

  1. Enter operational mode in the CLI.
  2. Rotate log files and identify the files that you can safely delete.

    The device rotates log files and displays the files that you can delete.

  3. Enter yes at the prompt to delete the files.
Note:

You can issue the request system storage cleanup dry-run command to review the list of files that you can safely delete . The dry-run action lets you review the list before you issue the request system storage cleanup command to delete the files.
Note:

On SRX Series Firewalls, the /var hierarchy is hosted in a separate partition (instead of the root partition). If the operating system installation fails as a result of insufficient space:

  • Use the request system storage cleanup command to delete temporary files.

  • Delete any user-created files in both the root partition and under the /var hierarchy.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
16.2R2
Beginning with Junos OS Release 16.2R2, the show | compare | display xml command omits the <configuration> tag in the XML output if the comparison returns no differences or if the comparison returns only differences for non-native configuration data, for example, configuration data associated with an OpenConfig data model.