ON THIS PAGE
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:
user@host> show configuration | compare | display xml
Example in configuration mode:
[edit]
user@host# show | compare | display xml
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.
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.
- Adding a Statement (create Operation)
- Deleting a Statement (delete Operation)
- Changing a Statement (delete and create Operations)
- Changing Metadata (inactive Attribute and Operation)
- Adding an Annotation (comment Tag and create Operation)
- Changing an Annotation (comment Tag, and delete and create Operations)
- Adding a Statement Inside a Container (create Operation, and insert and key Attributes)
- Changing the Order Inside a Container (merge Operation, and insert and key Attributes)
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.
[edit interfaces ge-0/0/0] user@host>show configuration | compare[edit interfaces ge-0/0/0] + unit 1 { + family inet { + address 2.2.2.2/32; + } + } [edit interfaces ge-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>ge-0/0/0</name> <unit nc:operation="create"> <name>1</name> <family> <inet> <address> <name>2.2.2.2/32</name> </address> </inet> </family> </unit> </interface> </interfaces> </configuration>
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.
[edit system] user@host>show configuration | compare[edit system] - services { - ftp; - } [edit system] user@host#show | compare | display xml<configuration> <system> <services operation="delete"/> </system> </configuration>
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.
[edit interfaces ge-0/0/0] user@host>show configuration | compare[edit interfaces ge-0/0/0] - unit 1 { - family inet { - address 2.2.2.2/32; - } - } [edit interfaces ge-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>ge-0/0/0</name> <unit nc:operation="delete"> <name>1</name> </unit> </interface> </interfaces> </configuration>
The following example shows the deletion of the apply-groups configuration. The groups that are deleted are not output.
[edit] user@host#delete apply-groups[edit] user@host>show configuration | compare[edit] - apply-groups [ g1 g2 g3 ]; [edit] user@host#show | compare | display xml<configuration> <apply-groups operation="delete"/> </configuration>
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.
[edit system] user@host>show configuration | compare[edit system] - host-name router1; + host-name router2; [edit system] user@host#show | compare | display xml<configuration> <system> <host-name nc:operation="delete"/> <host-name nc:operation="create">router2</host-name> </system> </configuration>
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.
[edit system] user@host>show configuration | compare[edit system] ! inactive: syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <syslog inactive="inactive"/> </system> </configuration>
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.
[edit system] user@host>show configuration | compare[edit system] + inactive: syslog { + file foo { + any any; + } + } [edit system] user@host#show | compare | display xml<configuration> <system> <syslog nc:operation="create" inactive="inactive"> <file> <name>foo</name> <contents> <name>any</name> <any/> </contents> </file> </syslog> </system> </configuration>
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.
[edit system] user@host>show configuration | compare[edit system] + /* my-comments-simple */ syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <junos:comment nc:operation="create">/* my-comments-simple */</junos:comment> <syslog/> </system> </configuration>
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.
[edit system syslog] user@host>show configuration | compare+ /* my-comments-ele */ file f1 { ... } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <junos:comment nc:operation="create">/* my-comments-elem */</junos:comment> <file> <name>f1</name> </file> </syslog> </system> </configuration>
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.
[edit system] user@host>show configuration | compare- /* my-comments-1 */ + /* my-comments-2 */ syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <junos:comment nc:operation="delete"/> <junos:comment nc:operation="create">/* my-comments-2 */</junos:comment> <syslog/> </system> </configuration>
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.
[edit system syslog] user@host>show configuration | compare[edit system syslog] file file-1 { ... } + file file-2 { + any any; + } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <file nc:operation="create" yang:insert="after" yang:key="[name='file-1']"> <name>file-2</name> <contents> <name>any</name> <any/> </contents> </file> </syslog> </system> </configuration>
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.
[edit system syslog] user@host>show configuration | compare[edit system syslog] file f1 { ... } ! file f3 { ... } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <file nc:operation="merge" yang:insert="after" yang:key="[name='file-1']"> <name>file-3</name> </file> </syslog> </system> </configuration>
See Also
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:
[edit]
user@host# rollback
load complete
To activate the configuration to which you rolled
back, use the commit command:
[edit] user@host#rollbackload complete [edit] user@host#commit
See Also
Returning to a Previously Committed Configuration
This topic explains how you can return to a configuration prior to the most recently committed one.
- Returning to a Configuration Prior to the One Most Recently Committed
- Displaying Previous Configurations
- Comparing Configuration Changes with a Prior Version
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.
[edit]
user@host# rollback number
load complete
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.
[edit]
user@host# rollback ?
Possible completions:
<[Enter]> Execute this command
<number> Numeric argument
0 2018-02-27 12:52:10 PST by abc via cli
1 2018-02-26 14:47:42 PST by def via cli
2 2018-02-14 21:55:45 PST by ghi via cli
3 2018-02-10 16:11:30 PST by jkl via cli
4 2018-02-10 16:02:35 PST by mno via cli
5 2018-03-16 15:10:41 PST by pqr via cli
6 2018-03-16 14:54:21 PST by stu via cli
7 2018-03-16 14:51:38 PST by vwx via cli
8 2018-03-16 14:43:29 PST by yzz via cli
9 2018-03-16 14:15:37 PST by abc via cli
10 2018-03-16 14:13:57 PST by def via cli
11 2018-03-16 12:57:19 PST by root via other
12 2018-03-16 10:45:23 PST by root via other
13 2018-03-16 10:08:13 PST by root via other
14 2018-03-16 01:20:56 PST by root via other
15 2018-03-16 00:40:37 PST by ghi via cli
16 2018-03-16 00:39:29 PST by jkl via cli
17 2018-03-16 00:32:36 PST by mno via cli
18 2018-03-16 00:31:17 PST by pqr via cli
19 2018-03-15 19:59:00 PST by stu via cli
20 2018-03-15 19:53:39 PST by vwx via cli
21 2018-03-15 18:07:19 PST by yzz via cli
22 2018-03-15 17:59:03 PST by abc via cli
23 2018-03-15 15:05:14 PST by def via cli
24 2018-03-15 15:04:51 PST by ghi via cli
25 2018-03-15 15:03:42 PST by jkl via cli
26 2018-03-15 15:01:52 PST by mno via cli
27 2018-03-15 14:58:34 PST by pqr via cli
28 2018-03-15 13:09:37 PST by root via other
29 2018-03-12 11:01:20 PST by stu via cli
30 2018-03-12 10:57:35 PST by vwx via cli
31 2018-03-11 10:25:07 PST by yzz via cli
32 2018-03-10 23:40:58 PST by abc via cli
33 2018-03-10 23:40:38 PST by def via cli
34 2018-03-10 23:14:27 PST by ghi via cli
35 2018-03-10 23:10:16 PST by jkl via cli
36 2018-03-10 23:01:51 PST by mno via cli
37 2018-03-10 22:49:57 PST by pqr via cli
38 2018-03-10 22:24:07 PST by stu via cli
39 2018-03-10 22:20:14 PST by vwx via cli
40 2018-03-10 22:16:56 PST by yzz via cli
41 2018-03-10 22:16:41 PST by abc via cli
42 2018-03-10 20:44:00 PST by def via cli
43 2018-03-10 20:43:29 PST by ghi via cli
44 2018-03-10 20:39:14 PST by jkl via cli
45 2018-03-10 20:31:30 PST by root via other
46 2018-03-10 18:57:01 PST by mno via cli
47 2018-03-10 18:56:18 PST by pqr via cli
48 2018-03-10 18:47:49 PST by stu via cli
49 2018-03-10 18:47:34 PST by vw via cli
| Pipe through a command
[edit]
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:
[edit]
user@host# show | compare (filename| rollback n)
filenameis the full path to a configuration file. The file must be in the proper format: a hierarchy of statements.nis 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:
[edit] user@host#edit protocols bgp[edit protocols bgp] user@host#showgroup my-group { type internal; hold-time 60; advertise-inactive; allow 10.1.1.1/8; } group fred { type external; peer-as 33333; allow 10.2.2.2/8; } group test-peers { type external; allow 10.3.3.3/8; } [edit protocols bgp] user@host#set group my-group hold-time 90[edit protocols bgp] user@host#delete group my-group advertise-inactive[edit protocols bgp] user@host#set group fred advertise-inactive[edit protocols bgp] user@host#delete group test-peers[edit protocols bgp] user@host#show | compare[edit protocols bgp group my-group] -hold-time 60; +hold-time 90; -advertise-inactive; [edit protocols bgp group fred] +advertise-inactive; [edit protocols bgp] -group test-peers { -type external; -allow 10.3.3.3/8; } [edit protocols bgp] user@host#showgroup my-group { type internal; hold-time 90; allow 10.1.1.1/8; } group fred { type external; advertise-inactive; peer-as 3333; allow 10.2.2.2/8; }
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:
[edit]
user@host# save filename
[edit]
user@host#
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.
user@host>file show /var/home/user/myconfreplace: protocols { bgp { disable; group int { type internal; } } isis { disable; interface all { level 1 disable; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; ... } }
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.
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-filesstatement at the[edit system]hierarchy level:[edit system] compress-configuration-files;
Commit the current configuration file to include the
compression-configuration-filesstatement. Commit the configuration again to compress the current configuration file:[edit system] user@host#
set compress-configuration-filesuser@host#commitcommit completeIf you do not want to compress the current operational configuration file, include the
no-compress-configuration-filesstatement at the[edit system]hierarchy level:[edit system] no-compression-configuration-files;
Commit the current configuration file to include the
no-compress-configuration-filesstatement. Commit the configuration again to uncompress the current configuration file:[edit system] user@host#
set no-compress-configuration-filesuser@host#commitcommit complete
See Also
Freeing 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 is displayed during a typical operation on the device after the file storage space is full.
user@host%cliuser@host>configure/var: write failed, filesystem is full
Solution
Clean up the file storage on the device by deleting system files.
Request to delete system files.
user@host>
request system storage cleanupThe list of files to be deleted is displayed.
List of files to delete: Size Date Name 11B Jul 26 20:55 /var/jail/tmp/alarmd.ts 124B Aug 4 18:05 /var/log/default-log-messages.0.gz 1301B Jul 26 20:42 /var/log/install.0.gz 387B Jun 3 14:37 /var/log/install.1.gz 4920B Aug 4 18:05 /var/log/messages.0.gz 20.0K Jul 26 21:00 /var/log/messages.1.gz 16.3K Jun 25 13:45 /var/log/messages.2.gz 804B Aug 4 18:05 /var/log/security.0.gz 16.8K Aug 3 11:15 /var/log/security.1.gz 487B Aug 4 18:04 /var/log/wtmp.0.gz 855B Jul 29 22:54 /var/log/wtmp.1.gz 920B Jun 30 16:32 /var/log/wtmp.2.gz 94B Jun 3 14:36 /var/log/wtmp.3.gz 353.2K Jun 3 14:37 /var/sw/pkg/jloader-qfx-11.2I20110303_1117_dc-builder.tgz 124.0K Jun 3 14:30 /var/tmp/gres-tp/env.dat 0B Apr 14 16:20 /var/tmp/gres-tp/lock 0B Apr 14 17:37 /var/tmp/if-rtsdb/env.lck 12.0K Jul 26 20:55 /var/tmp/if-rtsdb/env.mem 2688.0K Jul 26 20:55 /var/tmp/if-rtsdb/shm_usr1.mem 132.0K Jul 26 20:55 /var/tmp/if-rtsdb/shm_usr2.mem 2048.0K Jul 26 20:55 /var/tmp/if-rtsdb/trace.mem 155B Jul 26 20:55 /var/tmp/krt_gencfg_filter.txt 0B Jul 26 20:55 /var/tmp/rtsdb/if-rtsdb 1400.6K Aug 3 10:13 /var/tmp/sfid.core.0.gz 1398.9K Aug 3 17:01 /var/tmp/sfid.core.1.gz Delete these files ? [yes,no] (no)Enter
yesto delete the files.Reboot the device.
We recommend that you regularly request a system file storage cleanup to optimize the performance of the device.
See Also
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 (
*.tgzfiles) 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:
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, before
actually deleting the files.
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 cleanupcommand to delete temporary files.Delete any user-created files in both the root partition and under the
/varhierarchy.