Send Requests to the NETCONF Server
To initiate a request to the NETCONF server,
a client application emits the opening <rpc> tag, followed by one or more tag elements that represent the particular
request, and the closing </rpc> tag,
in that order:
<rpc>
<!-- tag elements representing a request -->
</rpc>
]]>]]>
The application encloses each request in its own separate pair
of opening <rpc> and closing </rpc> tags. Each request must constitute a well-formed
XML document by including only compliant and correctly ordered tag
elements. The NETCONF server ignores any newline characters, spaces,
or other white space characters that occur between tag elements in
the tag stream, but it preserves white space within tag elements.
Optionally, a client application can include one or more attributes
of the form attribute-name="value" in the opening <rpc> tag for each request. The NETCONF server echoes each attribute,
unchanged, in the opening <rpc-reply> tag in which it encloses its response.
A client application can use this feature to associate requests
and responses by including an attribute in each opening <rpc> request tag that assigns a unique identifier.
The NETCONF server echoes the attribute in its opening <rpc-reply> tag, making it easy to map the response
to the initiating request. The NETCONF specification specifies the
name message-id for this attribute.
Although operational and configuration requests conceptually
belong to separate classes, a NETCONF session does not have distinct
modes that correspond to CLI operational and configuration modes.
Each request tag element is enclosed within its own <rpc> tag, so a client application can freely alternate operational and
configuration requests. A client application can make three classes
of requests:
Operational Requests
Operational requests are requests for information
about the status of a device running Junos OS. Operational requests
correspond to the Junos OS CLI operational mode commands. The Junos
XML API defines a request tag element for many CLI commands. For example,
the <get-interface-information> tag
element corresponds to the show interfaces command, and
the <get-chassis-inventory> tag element
requests the same information as the show chassis hardware command.
The following RPC requests detailed information about interface ge-2/3/0:
<rpc>
<get-interface-information>
<interface-name>ge-2/3/0</interface-name>
<detail/>
</get-interface-information>
</rpc>
]]>]]>
For more information about operational requests, see Request Operational Information Using NETCONF. For information about the Junos XML request tag elements available in the current Junos OS Release, see the Junos XML API Operational Developer Reference and the XML API Explorer.
Configuration Information Requests
Configuration information requests are requests for information about the device’s candidate configuration, a private configuration, the ephemeral configuration, or the committed configuration (the one currently in active use on the switching, routing, or security platform). The candidate and committed configurations diverge when there are uncommitted changes to the candidate configuration.
The NETCONF protocol defines the <get-config> operation for retrieving configuration information. The Junos XML
API defines a tag element for every container and leaf statement in
the configuration hierarchy.
The following example shows how to request information from
the [edit system login] hierarchy level of the candidate
configuration:
<rpc>
<get-config>
<source>
<candidate/>
</source>
<filter type="subtree">
<configuration>
<system>
<login/>
</system>
</configuration>
</filter>
</get-config>
</rpc>
]]>]]>
For more information about configuration information requests, see Request Configuration Data Using NETCONF. For a summary of the available configuration tag elements, see the Junos XML API Configuration Developer Reference and the XML API Explorer.
Configuration Change Requests
Configuration change requests are requests
to change the configuration, or to commit those changes to put them
into active use on the device running Junos OS. The NETCONF protocol
defines the <edit-config> and <copy-config> operations for changing configuration
information. The Junos XML API defines a tag element for every CLI
configuration statement described in the Junos OS configuration guides.
The following example shows how to create a new Junos OS user
account called admin at the [edit system login] hierarchy level in the candidate configuration:
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration>
<system>
<login>
<user>
<name>admin</name>
<full-name>Administrator</full-name>
<class>superuser</class>
</user>
</login>
<login/>
</system>
</configuration>
</config>
</edit-config>
</rpc>
]]>]]>
For more information about configuration change requests, see Edit the Configuration Using NETCONF. For a summary of Junos XML configuration tag elements, see the Junos XML API Configuration Developer Reference and the XML API Explorer.