- play_arrow Manage Junos XML Protocol Sessions
- play_arrow Junos XML Protocol Session Overview
- play_arrow Manage Junos XML Protocol Sessions
- Satisfy the Prerequisites for Establishing a Connection to the Junos XML Protocol Server
- Configure clear-text or SSL Service for Junos XML Protocol Client Applications
- Connect to the Junos XML Protocol Server
- Start a Junos XML Protocol Session
- Authenticate with the Junos XML Protocol Server for Cleartext or SSL Connections
- Send Requests to the Junos XML Protocol Server
- Parse the Junos XML Protocol Server Response
- Parse Response Tag Elements Using a Standard API in NETCONF and Junos XML Protocol Sessions
- How Character Encoding Works on Juniper Networks Devices
- Handle an Error or Warning in Junos XML Protocol Sessions
- Halt a Request in Junos XML Protocol Sessions
- Lock, Unlock, or Create a Private Copy of the Candidate Configuration Using the Junos XML Protocol
- Terminate a Junos XML Protocol Session
- End a Junos XML Protocol Session and Close the Connection
- Sample Junos XML Protocol Session
- play_arrow Junos XML Protocol Tracing Operations
- play_arrow Junos XML Protocol Operations
- play_arrow Junos XML Protocol Processing Instructions
- play_arrow Junos XML Protocol Response Tags
- play_arrow Junos XML Element Attributes
- active
- count
- delete
- inactive
- insert
- junos:changed
- junos:changed-localtime
- junos:changed-seconds
- junos:commit-localtime
- junos:commit-seconds
- junos:commit-user
- junos:group
- junos:interface-range
- junos:key
- junos:position
- junos:total
- matching
- protect
- recurse
- rename
- replace
- replace-pattern
- start
- unprotect
- xmlns
-
- play_arrow Manage Configurations Using the Junos XML Protocol
- play_arrow Change the Configuration Using the Junos XML Protocol
- Request Configuration Changes Using the Junos XML Protocol
- Upload and Format Configuration Data in a Junos XML Protocol Session
- Upload Configuration Data as a File Using the Junos XML Protocol
- Upload Configuration Data as a Data Stream Using the Junos XML Protocol
- Define the Format of Configuration Data to Upload in a Junos XML Protocol Session
- Specify the Scope of Configuration Data to Upload in a Junos XML Protocol Session
- Replace the Configuration Using the Junos XML Protocol
- Create, Modify, or Delete Configuration Elements Using the Junos XML Protocol
- Create New Elements in Configuration Data Using the Junos XML Protocol
- Merge Elements in Configuration Data Using the Junos XML Protocol
- Replace Elements in Configuration Data Using the Junos XML Protocol
- Replace Only Updated Elements in Configuration Data Using the Junos XML Protocol
- Delete Elements in Configuration Data Using the Junos XML Protocol
- Rename Objects In Configuration Data Using the Junos XML Protocol
- Reorder Elements In Configuration Data Using the Junos XML Protocol
- Protect or Unprotect a Configuration Object Using the Junos XML Protocol
- Change a Configuration Element’s Activation State Using the Junos XML Protocol
- Change a Configuration Element’s Activation State Simultaneously with Other Changes Using the Junos XML Protocol
- Replace Patterns in Configuration Data Using the NETCONF or Junos XML Protocol
- play_arrow Commit the Configuration on a Device Using the Junos XML Protocol
- Verify Configuration Syntax Using the Junos XML Protocol
- Commit the Candidate Configuration Using the Junos XML Protocol
- Commit a Private Copy of the Configuration Using the Junos XML Protocol
- Commit a Configuration at a Specified Time Using the Junos XML Protocol
- Commit the Candidate Configuration Only After Confirmation Using the Junos XML Protocol
- Commit and Synchronize a Configuration on Redundant Control Planes Using the Junos XML Protocol
- Log a Message About a Commit Operation Using the Junos XML Protocol
- View the Configuration Revision Identifier for Determining Synchronization Status of Devices with NMS
- play_arrow Ephemeral Configuration Database
- Understanding the Ephemeral Configuration Database
- Unsupported Configuration Statements in the Ephemeral Configuration Database
- Enable and Configure Instances of the Ephemeral Configuration Database
- Commit and Synchronize Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol
- Managing Ephemeral Configuration Database Space
-
- play_arrow Request Operational and Configuration Information Using the Junos XML Protocol
- play_arrow Request Operational Information Using the Junos XML Protocol
- play_arrow Request Configuration Information Using the Junos XML Protocol
- Request Configuration Data Using the Junos XML Protocol
- Specify the Source for Configuration Information Requests in a Junos XML Protocol Session
- Specify the Output Format for Configuration Data in a Junos XML Protocol Session
- Request Commit-Script-Style XML Configuration Data Using the Junos XML Protocol
- Specify the Output Format for Configuration Groups and Interface Ranges Using the Junos XML Protocol
- Request Identifier Indicators for Configuration Elements Using the Junos XML Protocol
- Request Change Indicators for Configuration Elements Using the Junos XML Protocol
- Specify the Scope of Configuration Data to Return in a Junos XML Protocol Session
- Request the Complete Configuration Using the Junos XML Protocol
- Request a Configuration Hierarchy Level or Container Object Without an Identifier Using the Junos XML Protocol
- Request All Configuration Objects of a Specific Type Using the Junos XML Protocol
- Request a Specific Number of Configuration Objects Using the Junos XML Protocol
- Request Identifiers for Configuration Objects of a Specific Type Using the Junos XML Protocol
- Request a Single Configuration Object Using the Junos XML Protocol
- Request Subsets of Configuration Objects Using Regular Expressions
- Request Multiple Configuration Elements Using the Junos XML Protocol
- Retrieve a Previous (Rollback) Configuration Using the Junos XML Protocol
- Retrieve the Rescue Configuration Using the Junos XML Protocol
- Compare the Active or Candidate Configuration to a Prior Version Using the Junos XML Protocol
- Compare Two Previous (Rollback) Configurations Using the Junos XML Protocol
- Request an XML Schema for the Configuration Hierarchy Using the Junos XML Protocol
-
- play_arrow Junos XML Protocol Utilities
- play_arrow Develop Junos XML Protocol C Client Applications
-
- play_arrow Configuration Statements and Operational Commands
XML and Junos XML Management Protocol Conventions Overview
A client application must comply with XML and Junos XML management protocol conventions. Each request from the client application must be a well-formed XML document; that is, it must obey the structural rules defined in the Junos XML protocol and Junos XML document type definitions (DTDs) for the kind of information encoded in the request. The client application must emit tag elements in the required order and only in legal contexts. Compliant applications are easier to maintain in the event of changes to the Junos OS or Junos XML protocol.
Similarly, each response from the Junos XML protocol server constitutes a well-formed XML document (the Junos XML protocol server obeys XML and Junos XML management protocol conventions).
The following sections describe Junos XML management protocol conventions:
Request and Response Tag Elements
A request tag element is one generated
by a client application to request information about a device’s
current status or configuration, or to change the configuration. A
request tag element corresponds to a CLI operational or configuration
command. It can occur only within an <rpc>
tag. For information about the <rpc>
element, see Sending Requests to the
Junos XML Protocol Server.
A response tag element represents the Junos
XML protocol server’s reply to a request tag element and occurs
only within an <rpc-reply>
tag. For
information about the <rpc-reply>
element,
see Parsing the Junos XML Protocol Server
Response.
The following example represents an exchange in which a client
application emits the <get-interface-information>
request tag with the <extensive/>
flag
and the Junos XML protocol server returns the <interface-information>
response element.

This example, like all others in this guide, shows each tag element on a separate line, in the tag streams emitted by both the client application and Junos XML protocol server. In practice, a client application does not need to include newline characters between tag elements, because the server automatically discards such white space. For further discussion, see Spaces, Newline Characters, and Other White Space.
For information about the attributes in the opening rpc-reply
tag, see Parsing
the Junos XML Protocol Server Response. For information
about the xmlns
attribute in the opening <interface-information>
tag, see Requesting Operational Information Using the Junos
XML Protocol.
Child Tag Elements of a Request Tag Element
Some request tag elements contain child tag elements. For configuration requests, each child tag element represents a configuration element (hierarchy level or configuration object). For operational requests, each child tag element represents one of the options you provide on the command line when issuing the equivalent CLI command.
Some requests have mandatory child tag elements. To make a request successfully, a client application must emit the mandatory tag elements within the request tag element’s opening and closing tags. If any of the children are themselves container tag elements, the opening tag for each must occur before any of the tag elements it contains, and the closing tag must occur before the opening tag for another tag element at its hierarchy level.
In most cases, the client application can emit children that
occur at the same level within a container tag element in any order.
The important exception is a configuration element that has an identifier tag element, which distinguishes the configuration
element from other elements of its type. The identifier tag element
must be the first child tag element in the container tag element.
Most frequently, the identifier tag element specifies the name of
the configuration element and is called <name>
.
Child Tag Elements of a Response Tag Element
The child tag elements of a response tag element represent the individual data items returned by the Junos XML protocol server for a particular request. The children can be either individual tag elements (empty tags or tag element triples) or container tag elements that enclose their own child tag elements. For some container tag elements, the Junos XML protocol server returns the children in alphabetical order. For other elements, the children appear in the order in which they were created in the configuration.
The set of child tag elements that can occur in a response or within a container tag element is subject to change in later releases of the Junos XML API. Client applications must not rely on the presence or absence of a particular tag element in the Junos XML protocol server’s output, nor on the ordering of child tag elements within a response tag element. For the most robust operation, include logic in the client application that handles the absence of expected tag elements or the presence of unexpected ones as gracefully as possible.
Spaces, Newline Characters, and Other White Space
As dictated by the XML specification, the Junos XML protocol server ignores white space (spaces, tabs, newline characters, and other characters that represent white space) that occurs between tag elements in the tag stream generated by a client application. Client applications can, but do not need to, include white space between tag elements. However, they must not insert white space within an opening or closing tag. If they include white space in the contents of a tag element that they are submitting as a change to the candidate configuration, the Junos XML protocol server preserves the white space in the configuration database.
In its responses, the Junos XML protocol server includes white space between tag elements to enhance the readability of responses that are saved to a file: it uses newline characters to put each tag element on its own line, and spaces to indent child tag elements to the right compared to their parents. A client application can ignore or discard the white space, particularly if it does not store responses for later review by human users. However, it must not depend on the presence or absence of white space in any particular location when parsing the tag stream.
For more information about white space in XML documents, see the XML specification from the World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, at http://www.w3.org/TR/REC-xml/ .
XML Comments
Client applications and the Junos XML protocol server can insert XML comments at any point between tag elements in the tag stream they generate, but not within tag elements. Client applications must handle comments in output from the Junos XML protocol server gracefully but must not depend on their content. Client applications also cannot use comments to convey information to the Junos XML protocol server, because the server automatically discards any comments it receives.
XML comments are enclosed within the strings <!--
and -->
, and cannot contain the string - -
(two hyphens). For more details about comments,
see the XML specification at http://www.w3.org/TR/REC-xml/ .
The following is an example of an XML comment:
<!-- This is a comment. Please ignore it. -->
XML Processing Instructions
An XML processing instruction (PI) contains information relevant to a particular protocol and has the following form:
<?PI-name attributes?>
Some PIs emitted during a Junos XML protocol session include
information that a client application needs for correct operation.
A prominent example is the <?xml?>
element,
which the client application and Junos XML protocol server each emit
at the beginning of every Junos XML protocol session to specify which
version of XML and which character encoding scheme they are using.
For more information, see Starting Junos
XML Protocol Sessions.
The Junos XML protocol server can also emit PIs that the client application does not need to interpret (for example, PIs intended for the CLI). If the client application does not understand a PI, it must treat the PI like a comment instead of exiting or generating an error message.
Predefined Entity References
By XML convention, there are two contexts in which certain characters cannot appear in their regular form:
In the string that appears between opening and closing tags (the contents of the tag element)
In the string value assigned to an attribute of an opening tag
When including a disallowed character in either context, client applications must substitute the equivalent predefined entity reference, which is a string of characters that represents the disallowed character. Because the Junos XML protocol server uses the same predefined entity references in its response tag elements, the client application must be able to convert them to actual characters when processing response tag elements.
Table 1 summarizes the mapping between disallowed characters and predefined entity references for strings that appear between the opening and closing tags of a tag element.
Disallowed Character | Predefined Entity Reference |
---|---|
|
|
|
|
|
|
Table 2 summarizes the mapping between disallowed characters and predefined entity references for attribute values.
Disallowed Character | Predefined Entity Reference |
---|---|
|
|
|
|
> |
|
|
|
|
|
As an example, suppose that the following string is the value
contained by the <condition>
element:
if (a<b && b>c) return "Peer’s not responding"
The <condition>
element looks
like this (it appears on two lines for legibility only):
<condition>if (a<b && b>c) return "Peer’s not \ responding"</condition>
Similarly, if the value for the <example>
element’s heading
attribute is Peer’s "age" <> 40
, the opening
tag looks like this:
<example heading="Peer's "age" <> 40">