Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Try the Ask AI chatbot for answers to your technical questions about Juniper products and solutions.

close
header-navigation
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

Request Operational Information Using NETCONF

date_range 12-Jun-24

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.

Table 1: Examples of Request Tags and 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:

For example, the following command displays the request tag corresponding to the show interfaces command:

content_copy zoom_out_map
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.

content_copy zoom_out_map
<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.

Note:

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.

content_copy zoom_out_map
<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.

content_copy zoom_out_map
<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:

content_copy zoom_out_map
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.

content_copy zoom_out_map
<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.

content_copy zoom_out_map
<rpc-reply xmlns="URN" xmlns:junos="URL">
    operational-response
</rpc-reply>
]]>]]>
footer-navigation