ON THIS PAGE
Map 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 identifier { … configuration statements for individual characteristics … }
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:
keyword value;
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:
statement [ value1 value2 value3 ...];
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 (10.0.0.1), 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 defines 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.