- play_arrow Overview
- play_arrow Getting Started
- play_arrow Using Configuration Statements to Configure a Device
- play_arrow Using Operational Commands to Monitor Devices
- play_arrow Configuration Statements and Operational Commands
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:
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.
- Add a Statement (create Operation)
- Delete a Statement (delete Operation)
- Change a Statement (delete and create Operations)
- Change Metadata (inactive Attribute and Operation)
- Add an Annotation (comment Tag and create Operation)
- Change an Annotation (comment Tag, and delete and create Operations)
- Add a Statement Inside a Container (create Operation, and insert and key Attributes)
- Change the Order Inside a Container (merge Operation, and insert and key Attributes)
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.
[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>
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.
[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 shown in the 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>
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.
[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>
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.
[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>
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.
[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>
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 thejunos:comment
tag indicates that a comment was deleted from the[edit system]
hierarchy at thesyslog
statement.The
operation="create"
attribute for thejunos:comment
tag indicates that a comment was added to the[edit system]
hierarchy for thesyslog
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>
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 thefile
tag indicates that afile
statement was added.The
yang:insert="after"
attribute indicates that the file was added after the position indicated by theyang: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>
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 thefile
tag indicates that an existingfile
statement was moved.The
yang:insert="after"
attribute indicates that the file was moved after the file in the position indicated by theyang: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>
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#rollback
load complete [edit] user@host#commit
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
- Example of Displaying Previous Configurations
- About Comparing Configuration Versions
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:
[edit]
user@host# rollback number
load complete
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:
[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]
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:
[edit]
user@host# show | compare (filename| rollback n)
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:
[edit] user@host#edit protocols bgp
[edit protocols bgp] user@host#show
group 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#show
group 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; }
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.
user@host> show system commit include-configuration-revision 0 2020-08-02 00:42:58 IST by user via cli re0-1596309177-4 1 2020-08-02 00:42:53 IST by user via cli re0-1596309173-3 2 2020-08-02 00:42:50 IST by user via cli re0-1596309170-2 3 2020-08-02 00:42:40 IST by user via other re0-1596309160-1
Alternatively, you can view the CRI for a specific rollback
number by issuing the show system rollback
number
configuration-revision
command.
user@host> show system rollback 0 configuration-revision The corresponding configuration revision is: re0-1596309177-4
Once you have the CRI string for a specific commit, you can view
that configuration with the show system
configuration revision
cri-string
command.
user@host> show system configuration revision re0-1596309177-4
You can compare 2 configurations by using the
compare
option with both CRIs.
user@host> show system configuration revision compare re0-1596309177-4 re0-1596309173-3
You can also use view the rollback number for a specific CRI by
including the rollback-number
cri-string
option.
user@host> show system configuration revision rollback-number re0-1596309160-1 The corresponding rollback number is: 3
Additionally, in configuration mode, you can roll back to a configuration by specifying the CRI instead of the rollback index.
[edit] user@host# rollback revision re0-1596309160-1 load complete [edit] user@host# commit
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.
Example:
user@host>file show /var/home/user/myconf
replace
: protocols { bgp { disable; group int { type internal; } } isis { disable; interface all { level 1 disable; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; ... } }
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.
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:content_copy zoom_out_map[edit system] compress-configuration-files;
Commit the current configuration file to include the
compression-configuration-files
statement. Commit the configuration again to compress the current configuration file:content_copy zoom_out_map[edit system] user@host#
set compress-configuration-files
user@host#commit
commit completeIf you do not want to compress the current operational configuration file, include the
no-compress-configuration-files
statement at the[edit system]
hierarchy level:content_copy zoom_out_map[edit system] no-compression-configuration-files;
Commit the current configuration file to include the
no-compress-configuration-files
statement. Commit the configuration again to uncompress the current configuration file:content_copy zoom_out_map[edit system] user@host#
set no-compress-configuration-files
user@host#commit
commit complete
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:
user@host%cli
user@host>configure
/var: write failed, filesystem is full
Solution
Clean up the file storage on the device by deleting system files.
Issue a request to clean up (delete) system files.
content_copy zoom_out_mapuser@host>
request system storage cleanup
The list of files to be deleted is displayed.
content_copy zoom_out_mapList 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)
Select
yes
to delete the files.Reboot the device.
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:
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.
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.
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.