- play_arrow Overview
- play_arrow NETCONF XML Management Protocol Overview
- play_arrow NETCONF and Junos XML Tags Overview
- XML and Junos OS Overview
- XML Overview
- XML and NETCONF XML Management Protocol Conventions Overview
- Map Junos OS Commands and Command Output to Junos XML Tag Elements
- Map Configuration Statements to Junos XML Tag Elements
- Using NETCONF Configuration Response Tag Elements in NETCONF Requests and Configuration Changes
-
- play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Session Overview
- play_arrow Manage NETCONF Sessions
- Establish an SSH Connection for a NETCONF Session
- NETCONF Sessions over Transport Layer Security (TLS)
- NETCONF and Shell Sessions over Enhanced Outbound HTTPS
- NETCONF Sessions over Outbound HTTPS
- NETCONF Call Home Sessions
- NETCONF Sessions
- Sample NETCONF Session
- How Character Encoding Works on Juniper Networks Devices
- Configure RFC-Compliant NETCONF Sessions
- NETCONF Monitoring
- NETCONF Event Notifications
- play_arrow NETCONF Tracing Operations
- play_arrow NETCONF Protocol Operations and Attributes
- play_arrow NETCONF Request and Response Tags
- play_arrow Junos XML Protocol Elements Supported in NETCONF Sessions
- <abort/>
- <abort-acknowledgement/>
- <checksum-information>
- <close-configuration/>
- <commit-configuration>
- <commit-results>
- <commit-revision-information>
- <database-status>
- <database-status-information>
- <end-session/>
- <get-checksum-information>
- <get-configuration>
- <load-configuration>
- <load-configuration-results>
- <lock-configuration/>
- <open-configuration>
- <reason>
- <request-end-session/>
- <routing-engine>
- <unlock-configuration/>
- <xnm:error>
- <xnm:warning>
- play_arrow Junos XML Protocol Element Attributes Supported in NETCONF Sessions
-
- play_arrow Manage Configurations Using NETCONF
- play_arrow Change the Configuration Using NETCONF
- Edit the Configuration Using NETCONF
- Upload and Format Configuration Data in a NETCONF Session
- Set the Edit Configuration Mode in a NETCONF Session
- Handle Errors While Editing the Candidate Configuration in a NETCONF Session
- Replace the Candidate Configuration Using NETCONF
- Roll Back Uncommitted Changes in the Candidate Configuration Using NETCONF
- Delete the Configuration Using NETCONF
- Change Individual Configuration Elements Using NETCONF
- Merge Configuration Elements Using NETCONF
- Create Configuration Elements Using NETCONF
- Delete Configuration Elements Using NETCONF
- Replace Configuration Elements Using NETCONF
- Replace Patterns in Configuration Data Using the NETCONF or Junos XML Protocol
- play_arrow Commit the Configuration Using NETCONF
- 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
- Example: Configure the Ephemeral Configuration Database Using NETCONF
-
- play_arrow NETCONF Utilities
- play_arrow NETCONF Perl Client
- play_arrow Develop NETCONF Perl Client Applications
- Write NETCONF Perl Client Applications
- Import Perl Modules and Declare Constants in NETCONF Perl Client Applications
- Connect to the NETCONF Server in Perl Client Applications
- Collect Parameters Interactively in NETCONF Perl Client Applications
- Submit a Request to the NETCONF Server in Perl Client Applications
- Example: Request an Inventory of Hardware Components Using a NETCONF Perl Client Application
- Example: Change the Configuration Using a NETCONF Perl Client Application
- Parse the NETCONF Server Response in Perl Client Applications
- Close the Connection to the NETCONF Server in Perl Client Applications
-
- play_arrow YANG
- play_arrow YANG Overview
- Understanding YANG on Devices Running Junos OS
- Understanding Junos YANG Modules
- YANG Modules Overview
- Understanding the YANG Modules That Define the Junos OS Configuration
- Understanding the YANG Modules for Junos Operational Commands
- Junos Genstate YANG Data Models
- Understanding the Junos DDL Extensions YANG Module
- YANG Metadata Annotations for Junos Devices
- Use Juniper Networks YANG Modules
- play_arrow Create and Use Non-Native YANG Modules
- Understanding the Management of Nonnative YANG Modules on Devices Running Junos OS
- Manage YANG Packages, Modules, and Scripts on Junos Devices
- Managing YANG Packages and Configurations During a Software Upgrade or Downgrade
- Create Translation Scripts for YANG Configuration Models
- Disable and Enable YANG Translation Scripts on Devices Running Junos OS
- Commit and Display Configuration Data for Nonnative YANG Modules
- Create Custom RPCs in YANG for Devices Running Junos OS
- Create Action Scripts for YANG RPCs on Junos Devices
- Use Custom YANG RPCs on Devices Running Junos OS
- Example: Use a Custom YANG RPC to Retrieve Operational Information on Junos Devices
- Understanding Junos OS YANG Extensions for Formatting RPC Output
- Customize YANG RPC Output on Devices Running Junos OS
- Define Different Levels of Output in Custom YANG RPCs for Junos Devices
- Display Valid Command Option and Configuration Statement Values in the CLI for Custom YANG Modules
- Configure a NETCONF Proxy Telemetry Sensor in Junos
-
- play_arrow OpenDaylight Integration
- play_arrow Configure OpenDaylight Integration
-
- play_arrow Configuration Statements and Operational Commands
Request Operational Information Using NETCONF
Within a NETCONF session, a client application can request information about the current status of a Junos device. To request operational information, a client application emits the specific request tag element from the Junos XML API that returns the desired information.
Table 1 provides examples of request tags, which request the same information as the equivalent CLI command.
Request Tag | CLI Command |
---|---|
<get-interface-information> | show interfaces |
<get-chassis-inventory> | show chassis hardware |
<get-system-inventory> | show software information |
You can determine the appropriate Junos XML request tag using multiple methods, including:
Appending
| display xml rpc
to an operational command in the CLI.Using the Junos XML API Explorer - Operational Tags application to search for a command or request tag in a given release.
For example, the following command displays the request tag corresponding to the
show interfaces
command:
user@router> show interfaces | display xml rpc <rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.4R1.9/junos"> <rpc> <get-interface-information> </get-interface-information> </rpc> </rpc-reply>
To execute an RPC, the client application encloses a request tag in an
<rpc>
element. The syntax depends on whether the
corresponding CLI command has any options included.
<rpc> <!-- If the command does not have options --> <operational-request/> <!-- If the command has options --> <operational-request> <!-- tag elements representing the options --> </operational-request> </rpc> ]]>]]>
The client application can specify the formatting of the information returned by the
NETCONF server. By setting the optional format
attribute in the
opening operational request tag, a client application can specify the format of the
response as either XML-tagged format, which is the default, formatted ASCII text, or
JavaScript Object Notation (JSON). For more information about specifying the format,
see Specify the Output Format for Operational Information Requests in a NETCONF Session.
When displaying operational or configuration data that contains characters outside the 7-bit ASCII character set, Junos OS escapes and encodes these character using the equivalent UTF-8 decimal character reference. For more information see How Character Encoding Works on Juniper Networks Devices.
If the client application requests XML output, the NETCONF server encloses its
response in the specific response tag element that corresponds to the request tag
element, which is then enclosed in an <rpc-reply>
tag
element.
<rpc-reply xmlns="URN" xmlns:junos="URL"> <operational-response xmlns="URL-for-DTD"> <!-- tag elements for the requested information --> </operational-response> </rpc-reply> ]]>]]>
For example, if the client application sends the
<get-interface-information>
RPC, the NETCONF server
returns the <interface-information>
response tag.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/23.4R1.9/junos"> <interface-information xmlns="http://xml.juniper.net/junos/23.4R1.9/junos-interface" junos:style="normal"> <physical-interface> <name> ge-0/0/0 </name> <admin-status junos:format="Enabled"> up </admin-status> ...
For XML format, the opening tag for each operational response includes the
xmlns
attribute. The attribute defines the XML namespace for
the enclosed tag elements that do not have a namespace prefix (such as
junos:
). The namespace indicates which Junos XML document type
definition (DTD) defines the set of tag elements in the response.
The Junos XML API defines separate DTDs for operational responses from different software modules. For instance, the DTD for interface information is called junos-interface.dtd and the DTD for chassis information is called junos-chassis.dtd. The division into separate DTDs and XML namespaces means that a tag element with the same name can have distinct functions depending on which DTD it is defined in.
The namespace is a URL of the following form:
http://xml.juniper.net/junos/release-code/junos-category
where:
release-code is the standard string that represents the Junos OS release that is running on the NETCONF server device.
category specifies the DTD.
If the client application requests the output in formatted ASCII text, the NETCONF
server encloses its response in an <output>
tag element,
which is enclosed in an <rpc-reply>
tag.
<rpc-reply xmlns="URN" xmlns:junos="URL"> <output> operational-response </output> </rpc-reply> ]]>]]>
If the client application requests the output in JSON format, the NETCONF server
encloses the JSON data in the <rpc-reply>
tag element.
<rpc-reply xmlns="URN" xmlns:junos="URL"> operational-response </rpc-reply> ]]>]]>