Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Mapping Configuration Statements to Junos XML Tag Elements


The Junos XML API defines a tag element for every container and leaf statement in the configuration hierarchy. At the top levels of the configuration hierarchy, there is almost always a one-to-one mapping between tag elements and statements, and most tag names match the configuration statement name. At deeper levels of the hierarchy, the mapping is sometimes less direct, because some CLI notational conventions do not map directly to XML-compliant tagging syntax.


For some configuration statements, the notation used when you type the statement at the CLI configuration-mode prompt differs from the notation used in a configuration file. The same Junos XML tag element maps to both notational styles.

The following sections describe the mapping between configuration statements and Junos XML tag elements:

Mapping for Hierarchy Levels and Container Statements

The <configuration> element is the top-level Junos XML container element for configuration statements. It corresponds to the [edit] hierarchy level in CLI configuration mode. Most statements at the next few levels of the configuration hierarchy are container statements. The Junos XML container tag element that corresponds to a container statement almost always has the same name as the statement.

The following example shows the Junos XML tag elements for two statements at the top level of the configuration hierarchy. Note that a closing brace in a CLI configuration statement corresponds to a closing Junos XML tag.

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 consists of a keyword and identifier of the following form:

keyword is a fixed string that indicates the type of object being defined, and identifier is the unique name for this instance of the type. In the Junos XML API, the tag element corresponding to the keyword is a container tag element for child tag elements that represent the object’s characteristics. The container tag element’s name generally matches the keyword string.

The Junos XML API differs from the CLI in its treatment of the identifier. Because the Junos XML API does not allow container tag elements to contain both other tag elements and untagged character data such as an identifier name, the identifier must be enclosed in a tag element of its own. Most frequently, identifier tag elements for configuration objects are called <name>. Some objects have multiple identifiers, which usually have names other than <name>. To verify the name of each identifier tag element for a configuration object, consult the entry for the object in the Junos XML API Configuration Developer Reference.


The 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-.

Identifier tag elements also constitute an exception to the general XML convention that tag elements at the same level of hierarchy can appear in any order; the identifier tag element always occurs first within the container tag element.

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 Junos XML mapping for leaf statements, see Mapping for Single-Value and Fixed-Form Leaf Statements, Mapping for Leaf Statements with Multiple Values, and Mapping for Multiple Options on One or More Lines.

The following example shows the Junos XML tag elements for configuration statements that define two BGP groups called <name> and <name>. Notice that the Junos XML <name> element that encloses the identifier of each group (and the identifier of the neighbor within a group) does not have a counterpart in the CLI statements.

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:

In general, the name of the Junos XML tag element corresponding to a leaf statement is the same as the keyword string. The string between the opening and closing Junos XML tags is the same as the value string.

The following example shows the Junos XML tag elements 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.

Some leaf statements consist of a fixed-form keyword only, without an associated variable-form value. The Junos XML API represents such statements with an empty tag. The following example shows the Junos XML tag elements for the disable statement at the [edit forwarding-options sampling] hierarchy level.

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:

The Junos XML API instead encloses each value in its own tag element. The following example shows the Junos XML tag elements for a CLI statement with multiple user-defined values. The import statement imports two routing policies defined elsewhere in the configuration.

The following example shows the Junos XML tag elements for a CLI statement with multiple predefined values. The permissions statement grants three predefined permissions to members of the user-accounts login class.

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. The Junos XML API encloses each option in its own tag element. Because the first option has no keyword in the CLI statement, the Junos XML API assigns a name to its tag element.

The following example shows the Junos XML tag elements for a CLI configuration statement with multiple options on a single line. The Junos XML API defines a tag element for both options and assigns a name to the tag element for the first option (, which has no CLI keyword.

The syntax for some configuration objects includes more than one multioption line. Again, the Junos XML API defines a separate tag element for each option. The following example shows Junos XML tag elements for a traceoptions statement at the [edit protocols isis] hierarchy level. The statement has three child statements, each with multiple options.

Mapping for Comments About Configuration Statements

A Junos OS configuration can include comments that describe statements in the configuration. In CLI configuration mode, the annotate command specifies the comment to associate with a statement at the current hierarchy level. You can also use a text editor to insert comments directly into a configuration file. For more information, see the CLI User Guide.

The Junos XML API encloses comments about configuration statements in the <junos:comment> element. (These comments are different from the comments that are enclosed in the strings <!-- and --> and are automatically discarded by the protocol server.)

In the Junos XML API, the <junos:comment> element immediately precedes the element for the associated configuration statement. (If the tag element for the associated statement is omitted, the comment is not recorded in the configuration database.) The comment text string can include one of the two delimiters that indicate a comment in the configuration database: either the # character before the comment or the paired strings /* before the comment and */ after it. If the client application does not include the delimiter, the protocol server adds the appropriate one when it adds the comment to the configuration. The protocol server also preserves any white space included in the comment.

The following example shows the Junos XML tag elements that associate comments with two statements in a sample configuration statement. The first comment illustrates how including newline characters in the contents of the <junos:comment> element (/* New backbone area */) results in the comment appearing on its own line in the configuration file. There are no newline characters in the contents of the second <junos:comment> element, so in the configuration file the comment directly follows the associated statement on the same line.