ON THIS PAGE
Map Junos OS Configuration Statements to JSON
A configuration for a device running Junos OS is stored as a hierarchy of statements. The configuration statement hierarchy has two types of statements:
container statements—statements that contain other statements
leaf statements—statements that do not contain other statements
All of the container and leaf statements together form the configuration hierarchy.
The configuration hierarchy can be represented using JavaScript
Object Notation (JSON) in addition to formatted ASCII text, Junos
XML elements, and configuration mode set commands. Starting
in Junos OS Release 14.2, you can view the configuration of a device
running Junos OS in JSON format by executing the show configuration
| display json command in the CLI. In addition, starting in
Junos OS Release 16.1, you can load JSON-formatted configuration data
on the device.
Starting in Junos OS Release 16.1, devices running Junos OS emit JSON-formatted configuration
data using a new default implementation for serialization. You can explicitly configure
the new default, ietf, or revert to the previous default,
verbose, by configuring the appropriate statement at the
[edit system export-format json] hierarchy level.
Starting in Junos OS Releases 16.1R4, 16.2R2, and 17.1R1, integers in Junos OS configuration data emitted in JSON format are not enclosed in quotation marks. In earlier releases, integers in JSON configuration data are treated as strings and enclosed in quotation marks.
The following sections describe the mapping between the formatted ASCII text and the default format used for Junos OS configuration statements in JSON:
Mapping for Hierarchy Levels and Container Statements
The Junos OS configuration hierarchy is represented in JSON
by a JSON object with a single top-level member, or name/value pair,
that has the field name set to "configuration" and a value that contains a JSON object representing the entire
configuration. The configuration member
corresponds to the [edit] hierarchy level in CLI configuration
mode. Most statements at the next few levels of the configuration
hierarchy are container statements.
In JSON, each Junos OS hierarchy level or container statement is a member of its parent object. The member, or name/value pair, has a field name corresponding to the name of the hierarchy or container. Its value is a JSON object that contains members representing the child containers and leaf statements at that hierarchy level. The object might also contain a member that holds the list of attributes, if any, associated with that hierarchy.
The following example shows the mapping between formatted ASCII text and JSON for two statements at the top level of the configuration hierarchy:
CLI Configuration Statements
system {
login {
...child statements...
}
}
protocols {
ospf {
...child statements...
}
}JSON Syntax
{
"configuration" : {
"system" : {
"login" : {
...JSON configuration data...
}
}
"protocols" : {
"ospf" : {
...JSON configuration data...
}
}
}
}Mapping for Objects That Have an Identifier
At some hierarchy levels, the same kind of configuration object can occur multiple times. Each instance of the object has a unique identifier to distinguish it from the other instances. In the CLI notation, the parent statement for such an object might consist of a keyword and identifier or just an identifier.
keyword identifier {
… configuration statements for individual characteristics …
}
keyword is a fixed string that
indicates the type of object being defined, and identifier is a unique name for an instance of that type. In the following
example, user is a keyword, and username is the identifier.
user username {
/* child statements */
}
In JSON, all instances of a configuration object are contained
within a single name/value pair in which the field name generally
matches the keyword string, and the
value is an array of JSON objects, each of which is an instance of
the configuration object. The JSON syntax differs from the CLI in
its treatment of the identifier. In JSON, each instance of the configuration
object uses a name/value pair for the identifier, where the field
name distinguishes this data as the identifier, and the value is the
actual unique identifier for the object. Most frequently, the field
name is just name. Some objects have multiple
identifiers, and might use a field name other than name. JSON data that specifies an identifier is always listed first within
the corresponding object, but after any attribute list included for
that object.
{
"keyword" : [
{
"@" : {
"comment" : "comment"
},
"name" : "identifier",
JSON data for individual characteristics
},
{
"name" : "identifier",
JSON data for individual characteristics
}
]
}Junos OS reserves the prefix junos- for the identifiers of configuration groups defined within the junos-defaults configuration group. User-defined identifiers
cannot start with the string junos-.
The configuration for most objects that have identifiers includes
additional leaf statements, which represent other characteristics
of the object. For example, each BGP group configured at the [edit protocols bgp group] hierarchy level has
an associated name (the identifier) and can have leaf statements for
other characteristics such as type, peer autonomous system (AS) number,
and neighbor address. For information about the JSON mapping for leaf
statements, see Mapping for Single-Value and Fixed-Form Leaf Statements.
The following example shows the mapping of formatted ASCII text
to JSON for configuration statements that define two BGP groups named
G1 and G2. In the JSON syntax, the group member’s value is an array that contains a separate JSON object
for each BGP group.
CLI Configuration Statements
protocols {
bgp {
group G1 {
type external;
peer-as 64501;
neighbor 10.0.0.1;
}
group G2 {
type external;
peer-as 64502;
neighbor 10.0.10.1;
}
}
}
JSON Syntax
{
"configuration" : {
"protocols" : {
"bgp" : {
"group" : [
{
"name" : "G1",
"type" : "external",
"peer-as" : "64501",
"neighbor" : [
{
"name" : "10.0.0.1"
}
]
},
{
"name" : "G2",
"type" : "external",
"peer-as" : "64502",
"neighbor" : [
{
"name" : "10.0.10.1"
}
]
}
]
}
}
}
}
Mapping for Single-Value and Fixed-Form Leaf Statements
A leaf statement is a CLI configuration statement that does not contain any other statements. Most leaf statements define a value for one characteristic of a configuration object and have the following form:
keyword value;
Junos OS leaf statements are mapped to name/value pairs in JSON.
In general, the field name is the same as the keyword string,
and the value is the same as the value string.
The following example shows the JSON mapping for two leaf statements
that have a keyword and a value: the message statement
at the [edit system login] hierarchy level and
the preference statement at the [edit protocols ospf] hierarchy level.
CLI Configuration Statements
system {
login {
message "Authorized users only.";
... other statements under login ...
}
}
protocols {
ospf {
preference 15;
... other statements under ospf ...
}
}JSON Syntax
{
"configuration" : {
"system" : {
"login" : {
"message" : "Authorized users only.",
... JSON data for other statements under login ...
}
},
"protocols" : {
"ospf" : {
"preference" : "15",
... JSON data for other statements under ospf ...
}
}
}
}Some leaf statements consist of a fixed-form keyword only, without
an associated variable-form value. Junos OS represents such statements
in JSON by setting the value in the name/value pair to [null]. The following example shows the JSON mapping for the disable statement at the [edit forwarding-options sampling] hierarchy level.
CLI Configuration Statements
forwarding-options {
sampling {
disable;
}
}
JSON Syntax
{
"configuration" : {
"forwarding-options" : {
"sampling" : {
"disable" : [null]
}
}
}
}
Mapping for Leaf Statements with Multiple Values
Some Junos OS leaf statements accept multiple values, which can be either user-defined or drawn from a set of predefined values. CLI notation uses square brackets to enclose all values in a single statement, as in the following example:
keyword [ value1 value2 value3 ...];
As discussed in Mapping for Single-Value and Fixed-Form Leaf Statements, leaf statements are mapped to name/value pairs in JSON,
where the field name is the same as the keyword string. To represent multiple values, the value portion of
the JSON data uses an array of comma-separated strings.
The following example shows the JSON mapping for a CLI statement
with multiple user-defined values. The import statement
imports two routing policies defined elsewhere in the configuration.The formatted ASCII text
uses a space-separated list of values, whereas the JSON data uses
an array with a comma-separated list of strings.
CLI Configuration Statements
protocols {
bgp {
group 23 {
import [ policy1 policy2 ];
}
}
}JSON Syntax
{
"configuration" : {
"protocols" : {
"bgp" : {
"group" : [
{
"name" : "23",
"import" : ["policy1", "policy2"]
}
]
}
}
}
}
The following example shows the JSON mapping for a CLI statement
with multiple predefined values. The permissions statement
grants three predefined permissions to members of the user-accounts login class.
CLI Configuration Statements
system {
login {
class user-accounts {
permissions [ admin configure control ];
}
}
}
JSON Syntax
{
"configuration" : {
"system" : {
"login" : {
"class" : [
{
"name" : "user-accounts",
"permissions" : ["admin", "configure", "control"]
}
]
}
}
}
}
Mapping for Multiple Options on One or More Lines
For some Junos OS configuration objects, the standard CLI syntax places multiple options on a single line, usually for greater legibility and conciseness. In most such cases, the first option identifies the object and does not have a keyword, but later options are paired keywords and values.
In JSON, the same configuration object maps to a name/value pair. The field name is the same as the object name, and the value is a JSON object containing the options, which are represented by name/value pairs. If the first option has no keyword in the CLI statement, the JSON mapping assigns a name, which is equivalent to the option name defined in the schema and used for the corresponding Junos XML tag name.
The following example shows the JSON mapping for a CLI configuration
statement with multiple options on a single line. The JSON representation
of the [edit system backup-router] statement uses name/value
pairs for both options and assigns the field name address for the first option (10.0.0.1), which has no CLI keyword.
CLI Configuration Statements
system {
backup-router 10.0.0.1 destination 10.0.0.2/32;
}JSON Syntax
{
"configuration" : {
"system" : {
"backup-router" : {
"address" : "10.0.0.1",
"destination" : ["10.0.0.2/32"]
}
}
}
}
The syntax for some configuration objects includes more than one multi-option line. In JSON, the configuration object maps to a name/value pair, as in the previous case. The field name is the same as the object name, and the value is a JSON object containing the options, which are represented by name/value pairs. For each option, the field name is the same as the option name, and the value is a JSON data structure that appropriately represents the configuration data for that option. When an option uses the same keyword but spans multiple lines, the JSON representation combines the options into a single name/value pair. In this case, the value is an array of JSON objects in which each option is mapped to a separate object.
The following example shows the JSON mapping for the traceoptions statement at the [edit protocols isis] hierarchy
level. The traceoptions statement has three child statements,
each with multiple options. The CLI notation displays the individual flag options on separate lines, but the JSON representation
combines the flag details into a single name/value pair.
The value is an array of objects where each object contains the details
for one flag.
CLI Configuration Statements
protocols {
isis {
traceoptions {
file trace-file size 3m files 10 world-readable;
flag route detail;
flag state receive;
}
}
}
JSON Syntax
{
"configuration" : {
"protocols" : {
"isis" : {
"traceoptions" : {
"file" : {
"filename" : "isis-trace-file",
"size" : "3m",
"files" : 10,
"world-readable" : [null]
},
"flag" : [
{
"name" : "route",
"detail" : [null]
},
{
"name" : "state",
"receive" : [null]
}
]
}
}
}
}
}
Mapping for Attributes
The Junos OS configuration hierarchy can contain tags that modify
a hierarchy or statement. For example, if you issue the deactivate command to deactivate a statement in the configuration, the inactive: tag is prepended to the item in the configuration
to indicate this property. The Junos XML API represents this property
as an attribute in the opening tag of the XML element.
The JSON representation of the Junos OS configuration uses metadata annotations to represent these properties. The metadata annotations are encoded as members of a single JSON object and include the "@" symbol as or within the name.
The metadata object representing the attribute list for a container statement is added as a new member of that object. The metadata object is placed directly inside the container object it modifies and uses a single "@" symbol as the member name. The metadata object representing the attribute list for a leaf statement is added as a sibling name/value pair that is placed directly after the statement it modifies and that has a member name that is the concatenation of the "@" symbol and the statement name. The metadata object value in both cases is an object containing name/value pairs that describe each of the attributes associated with that container or leaf statement.
{
"container" : {
"@" : {
"attribute-name" : attribute-value,
"attribute-name" : attribute-value
},
"statement-name" : "statement-value",
"@statement-name" : {
"attribute-name" : attribute-value,
"attribute-name" : attribute-value
}
}
}
In the following examples, both the [edit commit] hierarchy and the persist-groups-inheritance statement
have been deactivated. In the CLI, the statements are preceded by
the inactive: tag. The Junos XML representation includes
the inactive="inactive" attribute in each
of the opening tags for those elements. The JSON mapping stores the
attributes in an attribute list. The attribute list for the [edit
commit] hierarchy is indicated with "@", because it is a container
statement. The attribute list for the persist-groups-inheritance statement is indicated using "@persist-groups-inheritance", because
it is a leaf statement.
CLI Configuration Statements
system {
inactive: commit {
inactive: persist-groups-inheritance;
}
}
XML Syntax
<configuration>
<system>
<commit inactive="inactive">
<persist-groups-inheritance inactive="inactive"/>
</commit>
</system>
</configuration>
JSON Syntax
{
"configuration" : {
"system" : {
"commit" : {
"@" : {
"inactive" : true
},
"persist-groups-inheritance" : [null],
"@persist-groups-inheritance" : {
"inactive" : true
}
}
}
}
}The attribute list for a specific instance of an object is similar to the attribute list for a container in that it is a name/value pair where the field name is a single "@" symbol, and the value is an object containing name/value pairs that describes each of the attributes. The attribute list is enclosed within the JSON object that identifies that instance and is the first member in the object, followed by the identifier for the object.
{
"keyword" : [
{
"@" : {
"attribute-name" : attribute-value
},
"name" : "identifier",
...JSON data for individual characteristics...
},
/* additional objects */
]
}In the following example, the ge-0/0/0 interface is protected.
In the CLI, the object is preceded by the protect: tag.
The Junos XML representation includes the protect="protect" attribute in the opening tag for that object. The JSON mapping stores
the "protect" : true attribute
in an attribute list that is included in the JSON object identifying
that specific interface.
CLI Configuration Statements
protect: ge-0/0/0 {
unit 0 {
family inet {
address 198.51.100.1/24;
}
}
}XML Syntax
<configuration>
<interfaces>
<interface protect="protect">
<name>ge-0/0/0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>198.51.100.1/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>JSON Syntax
{
"configuration" : {
"interfaces" : {
"interface" : [
{
"@" : {
"protect" : true
},
"name" : "ge-0/0/0",
"unit" : [
{
"name" : 0,
"family" : {
"inet" : {
"address" : [
{
"name" : "198.51.100.1/24"
}
]
}
}
}
]
}
]
}
}
}Mapping for Configuration Comments
A Junos OS configuration can include comments that describe
statements in the configuration. Configuration data formatted using
ASCII text or Junos XML elements displays comments on the line preceding
the statement that the comment modifies. In Junos XML format, the
comment string is enclosed in a <junos:comment> element.
Comments are indicated using one of two delimiters: the paired
strings /* and */ enclosing the comment, or the # character
preceding the comment. You can use either delimiter in the comment
string when you insert comments in the configuration. If you omit
the delimiter, Junos OS automatically inserts /* and */.
Junos OS preserves any white space included in the comment.
Junos OS configuration data formatted using JSON maps a comment
to a name/value pair that is stored as an attribute of the statement
that it modifies. The field name is set to "comment", and the value is the comment text string. The comment text string
can include either of the two delimiters that indicate a comment.
If you omit the delimiter from the comment text string when you load
the JSON configuration data, Junos OS automatically adds the /* and */ delimiters to
the comment. You can also create multiline comments in JSON configuration
data by inserting the newline character (\n) in the comment string.
The following example shows the formatted ASCII configuration and corresponding JSON syntax for three comments. The example associates one comment with a hierarchy, another comment with an object that has an identifier, and a third comment with a leaf statement.
CLI Configuration Statements
protocols {
/* New backbone area */
ospf {
area 0.0.0.0 {
/* From jnpr1
to jnpr2 */
interface so-0/0/0.0 {
# set by admin
hello-interval 5;
}
}
}
}
JSON Syntax
{
"configuration" : {
"protocols" : {
"ospf" : {
"@" : {
"comment" : "/* New backbone area */"
},
"area" : [
{
"name" : "0.0.0.0",
"interface" : [
{
"@" : {
"comment" : "/* From jnpr1 \n to jnpr2 */"
},
"name" : "so-0/0/0.0",
"hello-interval" : 5,
"@hello-interval" : {
"comment" : "# set by admin"
}
}
]
}
]
}
}
}
}
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.