Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


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:

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.

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