Sending 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:

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:

For more information about operational requests, see Requesting 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:

For more information about configuration information requests, see Requesting 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:

For more information about configuration change requests, see Editing 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.