Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Requesting A Specific Configuration Object Using NETCONF

In a NETCONF session with a device running Junos OS, to request complete information about a specific configuration object, a client application emits a <filter> tag element that encloses the tag elements representing all levels of the configuration hierarchy from the root (represented by the <configuration> tag element) down to the immediate parent level for the object.

To represent the requested object, the application emits its container tag element and each of its identifier tag elements, complete with identifier value. For objects with a single identifier, the <name> tag element can always be used, even if the actual identifier tag element has a different name. The actual name is also valid. For objects with multiple identifiers, the actual names of the identifier tag elements must be used. To verify the name of each of the identifiers for a configuration object, see the Junos XML API Configuration Reference. The entire request is enclosed in an <rpc> tag element:

<rpc><get-config><source><!--tag specifying the source configuration --> </source> <filter type="subtree"><configuration><!-- opening tags for each parent of the object --><object><name>identifier</name></object><!-- closing tags for each parent of the object --></configuration></filter ></get-config></rpc>
]]>]]>

For information about the <source> tag element, see Requesting Committed or Candidate Configuration Information Using NETCONF.

The NETCONF server returns the requested object in <data> and <rpc-reply> tag elements (here, an object for which the identifier tag element is called <name>). For information about the attributes in the opening <configuration> tag, see Requesting Committed or Candidate Configuration Information Using NETCONF.

<rpc-reply xmlns="URN" xmlns:junos="URL"><data><configuration attributes><!-- opening tags for each parent of the object --> <object><name>identifier</name><!-- other child tag elements of the object --></object><!-- closing tags for each parent of the object --></configuration></data></rpc-reply>
]]>]]>

The application can also request additional configuration elements of the same or other types by including the appropriate tag elements in the same <get-config> tag element. For more information, see Requesting Multiple Configuration Elements Simultaneously Using NETCONF.

The following example shows how to request the contents of one multicasting scope called local, which is at the [edit routing-options multicast] hierarchy level in the candidate configuration. To specify the desired object, the client application emits the <name>local</name> identifier tag element as the innermost tag element.

Published: 2013-07-26