Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Managing Configurations

 

Understanding 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 are 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 Junos OS namespace.

Note

Starting in 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 particular types of configuration changes. The corresponding text changes are shown for comparison.

Adding 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.

Deleting 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 output.

Changing 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 though is not output. The operation="create" attribute indicates that a host-name statement was created and is defined by the configuration within the host-name tag.

Changing 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.

Adding 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.

Changing 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.

Adding 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.

Changing 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 Junos OS 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 Junos OS Configuration

This topic explains how you can return to a configuration prior to the most recently committed one, and contains the following sections:

Returning to a Configuration Prior to the One Most Recently Committed

To return to a configuration prior to the most recently committed one, 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.

Displaying Previous Configurations

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

Comparing Configuration Changes with a Prior Version

In configuration mode only, when you have made changes to the configuration and want to compare the candidate configuration with a prior version, you can use the compare command to display the configuration. The compare command compares the candidate configuration with either the current committed configuration or a configuration file and displays the differences between the two configurations. To compare configurations, 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 candidate configuration is compared against the active configuration file (/config/juniper.conf).

The comparison output uses the following conventions:

  • Statements that are only in the candidate configuration are prefixed with a plus sign (+).

  • Statements that are only in the comparison file are prefixed with a minus sign (-).

  • Statements that are unchanged are prefixed with a single blank space ( ).

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

Saving a Configuration to a File

Save Junos OS configuration to a file so that you can edit it with a 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.

Compressing the Current Configuration File

By default, the current operational configuration file is compressed and is stored in the file juniper.conf.gz the /config file system, 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 operation 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, 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:

Freeing Up System Storage Space

Problem

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

The following error message is displayed during a typical operation on the switch after the file storage space is full.

Solution

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

  1. Request to delete system files on the switch.

    The list of files to be deleted is displayed.

  2. Enter yes to delete the files.
  3. Reboot the switch.
Best Practice

We recommend that you regularly request a system file storage cleanup to optimize the performance of the switch.

Understanding Automatic Refreshing of Scripts on EX Series Switches

You can automatically refresh commit, event, and op scripts using operational mode commands on EX Series switches. The commands are:

  • request system scripts refresh-from commit

  • request system scripts refresh-from event

  • request system scripts refresh-from op

The existing Junos operating system (Junos OS) command-line interface (CLI) refresh and refresh-from configuration mode statements have been extended to work with Junos XML management protocol and NETCONF XML management protocol sessions.

Cleaning 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 can be deleted.

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 can be safely deleted.

    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 can be deleted with the request system storage cleanup command, without actually deleting the files.

Note

On SRX Series devices, the /var hierarchy is hosted in a separate partition (instead of the root partition). If Junos OS 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.

Release History Table
Release
Description
Starting in 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.