Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

list Table of Contents
file_download PDF
keyboard_arrow_right

Managing Configurations

date_range 22-Nov-23

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:

content_copy zoom_out_map
user@host> show configuration | compare | display xml

Example in configuration mode:

content_copy zoom_out_map
[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.

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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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.

content_copy zoom_out_map
[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 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.

content_copy zoom_out_map
[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 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.

content_copy zoom_out_map
[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 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.

content_copy zoom_out_map
[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:

content_copy zoom_out_map
[edit]
user@host# rollback 
content_copy zoom_out_map
load complete

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

content_copy zoom_out_map
[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

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:

content_copy zoom_out_map
[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:

content_copy zoom_out_map
[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:

content_copy zoom_out_map
[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:

content_copy zoom_out_map
[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.

content_copy zoom_out_map
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.

content_copy zoom_out_map
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.

content_copy zoom_out_map
user@host> show system configuration revision re0-1596309177-4

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

content_copy zoom_out_map
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.

content_copy zoom_out_map
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.

content_copy zoom_out_map
[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:

content_copy zoom_out_map
[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:

content_copy zoom_out_map
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.

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:

    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 complete
    
  • 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:

    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:

content_copy zoom_out_map
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.

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

    content_copy zoom_out_map
    user@host> request system storage cleanup
    

    The list of files to be deleted is displayed.

    content_copy zoom_out_map
    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) 
  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.
    content_copy zoom_out_map
    user@host> request system storage cleanup
    

    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.
external-footer-nav
Ask AI
close

How can I help you today?

LLMs can make mistakes. Verify important information.
chat_add_on New topic
send progress_activity
This conversation will be monitored and recorded. Any information you provide will be subject to our Privacy Notice and may be used for quality assurance purposes. Do not include any personal or sensitive information. Ask AI can make mistakes. Verify generated output for accuracy.
Protected by hCaptcha arrow_drop_down arrow_drop_up
Juniper Networks, Inc. | Privacy Notice | Terms of Use