Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Loading Configuration Files

Loading configuration files on the device are helpful for loading parts of configuration files that might be common across many devices within a network.

Examples for Loading a Configuration from a File or the Terminal

You can create a file containing configuration data for a Juniper Networks device, copy the file to the local device, and then load the file into the CLI. After you have loaded the file, you can commit it to activate the configuration on the device, or you can edit the configuration interactively using the CLI and commit the configuration at a later time.

You can also create a configuration while typing at the terminal and then load the configuration. Loading a configuration from the terminal is useful when you are cutting existing portions of the configuration and pasting them elsewhere in the configuration.

To load an existing configuration file that is located on the device, you use the load configuration mode command:

To load a configuration from the terminal, you use the following version of the load configuration mode command. Press Ctrl-d to end the input.

To replace an entire configuration, you specify the override option at any level of the hierarchy. A load override operation completely replaces the current candidate configuration with the file you are loading. Thus, if you saved a complete configuration, you use this option.

An override operation discards the current candidate configuration and loads the configuration in filename or the configuration that you type at the terminal. When you use the override option and commit the configuration, all system processes reparse the configuration.

To replace portions of a configuration, you specify the replace option. The load replace operation looks for replace: tags that you added to the loaded file. The operation then replaces those parts of the candidate configuration with whatever is specified after the tag. This is useful when you want more control over exactly what is being changed. For this operation to work, you must include replace: tags in the file or configuration that you type at the terminal. The software searches for the replace: tags, deletes the existing statements of the same name, if any, and replaces them with the incoming configuration. If no statement of the same name exists, the replace operation adds to the configuration the statements marked with the replace: tag.

If, in an override or merge operation, you specify a file or type text that contains replace: tags, the replace: tags are ignored. In this scenario, the override or merge operation takes precedence and is performed.

If you are performing a replace operation, and if the file that you specify lacks replace: tags, the replace operation runs as a merge operation. The replace operation also runs as a merge operation if the text you type lacks replace: tags. This information might be useful if you are running automated scripts and cannot know in advance whether the scripts need to perform a replace operation or a merge operation. The scripts can use the replace operation to cover either case.

The load merge operation merges the configuration from the saved file or terminal with the existing candidate configuration. This information is useful if you are adding new configuration sections. For example, suppose that you are adding a BGP configuration to the [edit protocols] hierarchy level, where there was no BGP configuration before. You can use the load merge operation to combine the incoming configuration with the existing candidate configuration. If the existing configuration and the incoming configuration contain conflicting statements, the statements in the incoming configuration override those in the existing configuration.

To replace only those parts of the configuration that have changed, you specify the update option at any level of the hierarchy. The load update operation compares the candidate configuration and the new configuration data. This operation changes only those parts of the candidate configuration that are different from the new configuration. You would use this operation, for example, if there is an existing BGP configuration and the file you are loading changes it in some way.

The merge, override, and update options support loading configuration data in JavaScript Object Notation (JSON) format. When loading configuration data that uses JSON format, you must specify the json option in the command. To load JSON configuration data that contains unordered list entries, that is, list entries where the list key is not necessarily the first element in the list entry, see Load JSON Configuration Data With Unordered List Entries.

To change part of the configuration with a patch file, you specify the patch option. The load patch operation loads a file or terminal input that contains configuration changes. First, on a device that already has the configuration changes, you type the show | compare command to output the differences between two configurations. Then you can load the differences on another device. The advantage of the load patch command is that it saves you from having to copy snippets from different hierarchy levels into a text file before loading them into the target device. This might be a useful time saver if you are configuring several devices with the same options. For example, suppose that you configure a routing policy on router1 and you want to replicate the policy configuration on router2, router3, and router4. You can use the load patch operation.

In this example, you first run the show | compare command.

Example:

Continuing this example, you copy the output of the show | compare command to the clipboard, making sure to include the hierarchy levels. On router2, router3, and router4, you type load patch terminal and paste the output. You then press Enter and press Ctrl-d to end the operation. If the patch input specifies different values for an existing statement, the patch input overrides the existing statement.

To use the merge, replace, set, or update option without specifying the full hierarchy level, you specify the relative option. This option loads the incoming configuration relative to your current edit point in the configuration hierarchy.

Example:

To load a configuration that contains set configuration mode commands, specify the set option. This option executes the configuration instructions line by line as they are stored in a file or from a terminal. The instructions can contain any configuration mode command, such as set, edit, exit, and top.

To copy a configuration file from another network system to the local router, you can use the SSH and Telnet utilities, as described in the CLI Explorer.

Note:

If you are working in a Common Criteria environment, system log messages are created whenever a secret attribute is changed (for example, password changes or changes to the RADIUS shared secret). These changes are logged during the following configuration load operations:

How Character Encoding Works on Juniper Networks Devices

Junos OS Evolved configuration data and operational command output might contain non-ASCII characters, which are outside of the 7-bit ASCII character set. When displaying operational or configuration data in certain formats or within a certain type of session, the software escapes and encodes these characters. The software escapes or encodes the characters using the equivalent UTF-8 decimal character reference.

The CLI attempts to display any non-ASCII characters in configuration data that is produced in text, set, or JSON format. The CLI also attempts to display these characters in command output that is produced in text format. In the exception cases, the CLI displays the UTF-8 decimal character reference instead. (Exception cases include configuration data in XML format and command output in XML or JSON format,) In NETCONF and Junos XML protocol sessions, you see a similar result if you request configuration data or command output that contains non-ASCII characters. In this case, the server returns the equivalent UTF-8 decimal character reference for those characters for all formats.

For example, suppose the following user account, which contains the Latin small letter n with a tilde (ñ), is configured on the device.

When you display the resulting configuration in text format, the CLI prints the corresponding character.

When you display the resulting configuration in XML format in the CLI, the ñ character maps to its equivalent UTF-8 decimal character reference ñ. The same result occurs if you display the configuration in any format in a NETCONF or Junos XML protocol session.

When you load configuration data onto a device, you can load non-ASCII characters using their equivalent UTF-8 decimal character references.

About Specifying Statements and Identifiers

This topic provides details about CLI container statements and leaf statements so that you know how to must specify them when creating ASCII configuration files. This topic also describes how the CLI performs type checking to verify that the data you entered is in the correct format.

Specifying Statements

Statements are shown one of two ways, either with braces ({ }) or without:

  • Statement name and identifier, with one or more lower-level statements enclosed in braces:

  • Statement name, identifier, and a single identifier:

The statement-name is the name of the statement. The identifier-name is a name or other string that uniquely identifies an instance of a statement. You use an identifier when a statement can be specified more than once in a configuration.

When specifying a statement, you must specify a statement name, an identifier name, or both, depending on the statement hierarchy.

You specify identifiers in one of the following ways:

  • identifier-name—The identifier-name is a keyword used to uniquely identify a statement when a statement can be specified more than once in a statement.

  • identifier-name value—The identifier-name is a keyword, and the value is a required option variable.

  • identifier-name [value1 value2 value3 ...]—The identifier-name is a keyword that accepts multiple values. The brackets are required when you specify a set of values; however, they are optional when you specify only one value.

The following examples illustrate how statements and identifiers are specified in the configuration:

When you create an ASCII configuration file, you specify statements and identifiers. Each statement has a preferred style, and the CLI uses that style when displaying the configuration in response to a configuration mode show command. You can specify statements and identifiers in one of the following ways:

  • Statement followed by identifiers:

  • Statement followed by identifiers enclosed in braces:

  • For some repeating identifiers, you can use one set of braces for all the statements:

Performing CLI Type Checking

When you specify identifiers and values, the CLI performs type checking to verify that the data you entered is in the correct format. For example, for a statement in which you must specify an IP address, the CLI requires that you enter an address in a valid format. Otherwise, an error message indicates what you need to type. lists the data types the CLI checks. The following are CLI configuration input types:

Table 1: CLI Configuration Input Types

Data Type

Format

Examples

Physical interface name (used in the [edit interfaces] hierarchy)

type-fpc/pic/port

Correct: et-0/0/1

Incorrect: et-0

Full interface name

type-fpc/pic/port<:channel>.logical

Correct: et-0/0/1.0

Incorrect: et-0/0/1

Full or abbreviated interface name (used in places other than the [edit interfaces] hierarchy)

type-<fpc</pic/port>><<: channel>.logical>

Correct: et, et-1, et-1/2/3:4.5

IP address

0xhex-bytesoctet<. octet<.octet. <octet>>>

Correct: 1.2.3.4, 0x01020304, 128.8.1, 128.8

Sample translations:

1.2.3 becomes 1.2.3.00x01020304 becomes 1.2.3.40x010203 becomes 0.1.2.3

IP address (destination prefix) and prefix length

0xhex-bytes</length>octet<octet <octet.<octet>>></length>

Correct: 10/8, 128.8/16, 1.2.3.4/32, 1.2.3.4

Sample translations:

1.2.3 becomes 1.2.3.0/320x01020304 becomes 1.2.3.4/320x010203 becomes 0.1.2.3/32default becomes 0.0.0.0/0

International Organization for Standardization (ISO) address

hex-nibble<hex-nibble ...>

Correct: 47.1234.2345.3456.00, 47123423453456.00, 47.12.34.23.45.34.56.00

Sample translations:

47123456 becomes 47.1234.5647.12.34.56 becomes 47.1234.564712.3456 becomes 47.1234.56

OSPF area identifier (ID)

0xhex-bytesoctet<.octet<.octet.< octet >>> decimal-number

Correct: 54, 0.0.0.54, 0x01020304, 1.2.3.4

Sample translations:

54 becomes 0.0.0.54

257 becomes 0.0.1.1128.8 becomes 128.8.0.00x010203 becomes 0.1.2.3

About Loading a Configuration from a File

The following examples demonstrate the process of loading a configuration from a file.

Table 2: Overriding the Current Configuration

Current configuration:

interfaces {
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1;
   }
  }
 }
 et-3/0/0 {
  unit 0 {
   family inet {
    address 204.69.248.181/28;
   }
  }
 }
}

File contents:

interfaces {
replace:
 et-3/0/0 {
  unit 0 {
   family inet {
    address 10.0.0.1/8;
   }
  }
 }
}
load override
------------>

New contents:

interfaces {
 et-3/0/0 {
  unit 0 {
   family inet {
    address 10.0.0.1/8;
   }
  }
 }
}
Table 3: Using the replace Option

Current configuration:

interfaces {
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1;
   }
  }
 }
 et-3/0/0 {
  unit 0 {
   family inet {
    address 204.69.248.181/28;
   }
  }
 }
}

File contents:

interfaces {
replace:
 et-3/0/0 {
  unit 0 {
   family inet {
    address 10.0.0.1/8;
   }
  }
 }
}
load replace
------------>

New contents:

interfaces {
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1;
   }
  }
 }
et-3/0/0 {
 unit 0 {
  family inet {
   address 10.0.0.1/8;
   }
  }
 }
}
Table 4: Using the merge Option

Current configuration:

interfaces {
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1;
   }
  }
 }
 et-3/0/0 {
  unit 0 {
   family inet {
    address 204.69.248.181/28;
   }
  }
 }
}

File contents:

interfaces {
replace:
 et-3/0/0 {
  unit 0 {
   family inet {
    address 10.0.0.1/8;
   }
  }
 }
}
load merge
------------>

New contents:

interfaces {
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1;
   }
  }
 }
et-3/0/0 {
 unit 0 {
  family inet {
   address 10.0.0.1/8;
   address 204.69.248.181/28;
   }
  }
 }
}
Table 5: Using a Patch file

Current configuration:

interfaces {
 fxp0 {
  unit 0 {
   family inet {
    address 192.168.6.193/24;
   }
  }
 }
 Io0 {
  unit 0 {
   family inet {
    address 127.0.0.1/32;
   }
  }
 }
}

File contents:

{edit interfaces}
+ et-3/0/0 {
+  unit 0 {
+   family inet {
+    address 10.0.0.1/8;
+   }
+  }
+ }
load patch
------------>

New contents:

interfaces {
 et-0/0/0 {
  unit 0 {
   family inet {
    address 10.0.0.1/8;
   }
  }
 }
 fxp0 {
  unit 0 {
   family inet {
    address 192.168.6.193/24;
   }
  }
 }
Io0 {
 unit 0 {
  family inet {
   address 127.0.0.1/32;
   }
  }
 }
}
Figure 1: Using the set OptionUsing the set Option

Upload a Configuration File

You can create a configuration file on your local system, copy the file to the device, and then load the file into the CLI. After you have loaded the configuration file, you can commit it to activate the configuration on the device. You can also edit the configuration interactively using the CLI and commit it at a later time.

To upload a configuration file from your local system:

  1. Create the configuration file using a text editor such as Notepad, making sure that the syntax of the configuration file is correct.
  2. In the configuration text file, include one or more of the following options to perform the required action when the file is loaded.
    Table 6: Options for the load Command
    Options Description

    merge

    Combines the current active configuration with either the configuration in the filename that you specify or the configuration that you type in the terminal window. A merge operation is useful when you are adding a new section to an existing configuration. If the active configuration and the incoming configuration contain conflicting statements, the statements in the incoming configuration override those in the active configuration.

    override

    Discards the current candidate configuration. Loads either the configuration in the filename that you specify or the configuration that you type at the terminal. When you use the override option and commit the configuration, all system processes reparse the configuration. You can use the override option at any level of the hierarchy.

    replace

    Searches for the replace tags, deletes the existing statements of the same name, if any, and replaces the existing statements with the incoming configuration. If no statement of the same name exists, the replace operation adds the statements marked with the replace tag to the active configuration.

    Note:

    For this operation to work, you must include replace tags in the text file or in the configuration that you enter at the terminal.

  3. Press Ctrl+a to select all the text in the configuration file.
  4. Press Ctrl+c to copy the contents of the configuration text file to the Clipboard.
  5. Log in to the device using your username and password.
  6. Enter configuration mode: user@host> configure

    [edit] user@host#

  7. Load the configuration file: [edit] user@host# load merge terminal
  8. At the cursor, paste the contents of the Clipboard using the mouse and the Paste icon: [edit] user@host# load merge terminal [Type ^D at a new line to end input] >Cursor is here. Paste the contents of the clipboard here<
  9. Press Enter.
  10. Press Ctrl+d to set the end-of-file marker.

To view results of the configuration steps before committing the configuration, type the show command at the user prompt.

To commit these changes to the active configuration, type the commit command at the user prompt. You can also edit the configuration interactively using the CLI and commit it at a later time.

Load JSON Configuration Data With Unordered List Entries

The Junos schema defines certain configuration objects as lists. In JSON configuration data, a list instance is encoded as a name/array pair, and the array elements are JSON objects. Generally, the order of members in a JSON-encoded list entry is arbitrary because JSON objects are fundamentally unordered collections of members. However, the Junos schema requires that list keys precede any other siblings within a list entry and appear in the order specified by the schema.

For example, the user object at the [edit system login] hierarchy level is a list where name is the list key that uniquely identifies each user.

In the following sample configuration data, the list key (name) is the first element for each user. By default, when you load JSON configuration data, Junos devices require that the list keys precede any other siblings within a list entry and appear in the order specified by the schema.

Junos devices provide two options to load JSON configuration data that contains unordered list entries, that is, list entries where the list key is not necessarily the first element.

  • Use the request system convert-json-configuration operational mode command to produce JSON configuration data with ordered list entries before loading the data on the device.

  • Configure the reorder-list-keys statement at the [edit system configuration input format json] hierarchy level. After you configure the statement, you can load JSON configuration data with unordered list entries, and the device reorders the list keys as required by the Junos schema during the load operation.

Note:

When you configure the reorder-list-keys statement, the load operation can take significantly longer to parse the configuration, depending on the size of the configuration and the number of lists. Thus, for large configurations or configurations with many lists, we recommend using the request system convert-json-configuration command instead of the reorder-list-keys statement.

For example, suppose the user-data.json file contains the following JSON configuration. If you tried to load the configuration, the device would emit a load error for admin2 because the list key name is not the first element in that list entry.

If you use the request system convert-json-configuration command with the previous file as input, the command generates the specified output file with JSON configuration data that the Junos device can parse during the load operation.

Alternatively, you can configure the reorder-list-keys configuration statement.

After you configure the statement, you can load the original JSON configuration file with unordered list entries, and the device handles the list entries when it parses the configuration.