4.20 Saving, Modifying, and Loading Configuration Files

The JUNOS CLI provides tools that give you the option to save, modify, and load configuration files to and from different locations. Files can be uploaded and downloaded from an FTP server or stored locally on the router. The files can be saved in whole or in part. The JUNOS CLI also offers some useful tools for modifying and annotating the configuration files. The following sections explain all these features and give examples.

4.20.1 Saving Configuration Files

As in the operational mode, in configuration mode you can display the configuration and use the <save > option to save the configuration to the router or to an FTP server. You do this with the save command.

4.20.1.1 save

The first example below saves the configuration file on the router; the second example saves the configuration file to an FTP server.

The user lab saves a file named testfile locally.

 [edit]  lab@Chicago# save testfile Wrote 94 lines of configuration to 'testfile' 

Here the file is saved to an FTP server:

 [edit]  lab@Chicago# save ftp://192.168.161.9/testftp Receiving ftp://192.168.161.9/testftp (1832 bytes): 100% 1832 bytes transferred in 0.0 seconds (2.42 MBps) Wrote 94 lines of configuration to 'ftp://192.168.161.9/testftp' 

4.20.2 Modifying Configuration Files

When working in the CLI, you have the ability to annotate, copy, delete, rename, and insert configuration changes on a per-line or per-command basis. In addition to these editing features, you also have the ability to deactivate and activate specific sections of the configuration. This feature is especially useful for testing and for making changes ahead of time that may be enabled during a scheduled maintenance window. The following commands are arranged in logical order.

4.20.2.1 annotate

The annotate feature lets you store a note in the configuration. This annotation is a way to describe a section of the configuration. This example shows how to add an annotation to the configuration. It adds the annotation externalannotation to the bgp group named external .

 [edit protocols bgp]  lab@Chicago# annotate group external externalannotation [edit protocols bgp] lab@Chicago# show group internal {     type internal;     local-address 192.168.20.1;     neighbor 192.168.16.1; } /* externalannotation */ group external {     type external;     peer-as 2;     neighbor 10.0.23.2; 

4.20.2.2 copy

The copy feature can be quite useful. If you need to add many PVCs or add several users, instead of typing each one in individually, you could use the copy command to create new entries. The example below demonstrates copying the user named lab to a new user named labcopy :

 [edit]  lab@Chicago# copy system login user lab to user labcopy 

4.20.2.3 delete

The following command will delete the group named external from the protocols bgp hierarchy. If you wanted to disable bgp completely, you could use the delete protocols bgp command.

 [edit]  lab@Chicago# delete protocols bgp group external 

4.20.2.4 rename

The rename parameter does exactly that ”it allows you to change the name of a particular parameter without having to delete it. The example below renames the user labcopy to labcopy2 :

 [edit system login]  lab@Chicago# rename user labcopy to user labcopy2 

4.20.2.5 insert

The insert command comes in very handy when dealing with the arrangement and order of lines in the configuration file, especially when dealing with terms in policies. The insert command gives users the ability to move lines around and place them before or after other lines in the configuration file. The following example shows how you can move and insert a line before another in the configuration file.

Note

The insert command does not create new lines of configuration. In order for lines to be placed before or after other lines, the lines must already exist in the configuration file. In other words term 3 in this example must already be in the configuration before it can be inserted before term 2 .

 [edit policy-options policy-statement insert_test]  lab@Chicago# show term 1 {     from protocol static;     then accept; } term 2 {     from protocol bgp;     then accept; } term 3 {     from protocol ospf;     then accept; } lab@Chicago# insert term 3 before term 2 [edit policy-options policy-statement insert_test] lab@Chicago# show term 1 {     from protocol static;     then accept; } term 3 {     from protocol ospf;     then accept; } term 2 {     from protocol bgp;     then accept; } 

4.20.2.6 deactivate and activate

The commands deactivate and activate are CLI features that can be used to turn parameters off and on without deleting them or removing them from the configuration file. For instance, in the example below, if the user lab has left the company and will no longer need access to the router, you can deactivate his account by using the deactivate command. Notice that the user information is still included in the configuration, but it is listed as inactive. This command is also very useful for adding configurations to be activated later. Suppose that a new customer will be coming on board next month. We could install the configuration for the customer in an inactive state, and when the time is right, we can activate the customer's configuration for a very fast implementation.

 [edit system login]  lab@Chicago# deactivate user lab [edit system login] lab@Chicago# show class superuser-local {     permissions all; } inactive: user lab {     uid 2000; [edit system login] lab@Chicago# activate user lab [edit system login] lab@Chicago# show class superuser-local {     permissions all; } user lab {     uid 2000; 

4.20.3 Loading Configuration Files from the CLI

Loading configurations can be performed in the configuration mode by using the load command. There are three variations to the command:

1. load merge combines the contents of new file with the existing candidate configuration file.

2. load replace can be used to overwrite a specific section of the configuration.

3. load override will overwrite a complete configuration file.

4.20.3.1 load merge

The first output below shows the configured interfaces. At this time, the only interface is ge-1/0/0 . When the load merge command is used, the file named interfaces will be combined with the candidate configuration file. The result in this example is the addition of the so-6/0/0 interface.

 [edit]  lab@Chicago# show interfaces ge-1/0/0 {     unit 0 {         family inet {             address 10.0.21.2/24;         }         family iso;     } } [edit] lab@Chicago# load merge interfaces load complete [edit] lab@Chicago# show interfaces ge-1/0/0 {     unit 0 {         family inet {             address 10.0.21.2/24;         }         family iso;     } } so-6/0/0 {     unit 0 {         family inet {             address 10.0.23.1/24;         }         family iso;     } } 

4.20.3.2 load replace

The load replace command is used to replace specified sections within the configuration file. The sections to be replaced need to be marked with replace: tags. After completing the load replace , the inet address associated with the ge-1/0/0 interface has been changed.

 [edit]  lab@Chicago# show interfaces ge-1/0/0 {     unit 0 {         family inet {             address 10.0.21.2/24;         }         family iso; Contents of the replace_ge_inef file interfaces { replace: ge-1/0/0 {         unit 0 {             family inet {                 address 10.0.44.2/24;             }             family iso;         } [edit] lab@Chicago# load replace replace_ge_inet load complete [edit] lab@Chicago# show interfaces ge-1/0/0 {     unit 0 {         family inet {             address 10.0.44.2/24;         }         family iso; 

4.20.3.3 load override

The load override command is used for overwriting the complete configuration file. In the first part of the example below, the current configuration has the system host-name set to Chicago , and a user account setup for lab . The load file override has only a system host-name set and the services enabled. When the load override command is used, the filename override will overwrite the candidate configuration completely.

 [edit]  lab@Chicago# show version 5.1R1.4; system {     host-name Chicago;     login {         class superuser-local {             permissions all;         }         user lab {             uid 2000;             class superuser; [edit] lab@Chicago# load override override load complete [edit] lab@Chicago# show system {     host-name override;     login {         class superuser-local {             permissions all;         }         user lab {             uid 2000;             class superuser;             authentication {                 encrypted-password "$ /"; # SECRET-DATA             }         }     }     services {         ftp;         ssh;         telnet;     } } 

4.20.3.4 Loading Configurations from the Terminal

In the JUNOS CLI, it is also possible to enter configuration parameters in ASCII format, either by typing or pasting directly into the terminal. The following example shows how to do this. The user lab types load override terminal and pastes the configuration into the terminal. The command will end when the user types Ctrl-d.

Note

The load command is dependant on the level of hierarchy. If you are in the middle of the hierarchy and try loading a configuration with higher-level commands in it, it will error out. Therefore, this command will ONLY run at the top level.

 [edit]  lab@Chicago# load override terminal [Type ^D to end input] system {     host-name override;     login {         class superuser-local {             permissions all;         }         user lab {             uid 2000;             class superuser;             authentication {                 encrypted-password "$ /"; # SECRET-DATA             }         }     }     services {         ftp;         ssh;         telnet;     } } load complete 

Note

The terminal parameter is available with all three load commands.