Request Specific Child Tags for a Configuration Object Using NETCONF
In a NETCONF session with a device running Junos OS, to request specific child tag
elements and descendents for configuration objects, 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. To request a specific configuration object, include the identifier tag element. 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. If you omit the identifier tag element, the server returns the child
tags for all configuration objects of that type. To select specific child tags, the client
application emits all desired child tag elements and descendents within the container tag
element. 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>
<first-child/>
<second-child/>
<third-child>
<!--tags for descendents-->
</third-child>
<!-- tag for each additional child to return -->
</object>
<!-- closing tags for each parent of the object -->
</configuration>
</filter>
</get-config>
</rpc>
]]>]]>
For
information about the <source> tag element, see Specify the Source for Configuration Information Requests Using NETCONF.
The NETCONF server returns the requested children of the 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 Specify the Source for Configuration Information Requests Using NETCONF.
<rpc-reply xmlns="URN" xmlns:junos="URL">
<data>
<configuration attributes>
<!-- opening tags for each parent of the object -->
<object>
<name>identifier</name>
<!-- requested child tags -->
</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 Request Multiple Configuration Elements Simultaneously Using NETCONF.
The following example shows how to request only the address of the next-hop device
for the 192.168.5.0/24 route at the [edit routing-options static] hierarchy
level in the candidate configuration.
The following example shows how to request the addresses for all logical interfaces configured for each physical interface within the groups hierarchy level of the candidate configuration.
<rpc>
<get-config>
<source>
<candidate/>
</source>
<filter type="subtree">
<configuration>
<groups>
<interfaces>
<interface>
<unit>
<family>
<inet>
<address/>
</inet>
</family>
</unit>
</interface>
</interfaces>
</groups>
</configuration>
</filter>
</get-config>
</rpc><rpc-reply xmlns="URN" xmlns:junos="URL">
<data>
<configuration xmlns="URL" junos:commit-seconds=seconds junos:commit-localtime="timestamp" junos:commit-user="user">
<groups>
<name>re0</name>
<interfaces>
<interface>
<name>lo0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>127.0.0.1/32</name>
</address>
</inet>
</family>
</unit>
</interface>
<interface>
<name>em0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>198.51.100.1/24</name>
</address>
<address>
<name>198.51.100.11/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</groups>
</configuration>
</data>
</rpc-reply>