Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Requesting Identifiers for Configuration Objects of a Specified Type Using NETCONF

 

In a NETCONF session with a device running Junos OS, to request output that shows only the identifier for each configuration object of a specific type in a hierarchy, 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 type. The object type is represented by its container tag element enclosing an empty <name/> tag. (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.) The entire request is enclosed in an <rpc> tag element:

For information about the <source> tag element, see Specifying the Source for Configuration Information Requests Using NETCONF.

Note

You cannot request only identifiers for object types that have multiple identifiers. However, for many such objects the identifiers are the only child tag elements, so requesting complete information yields the same output as requesting only identifiers. For instructions, see Requesting All Configuration Objects of a Specified Type Using NETCONF.

The NETCONF server returns the requested objects in <data> and <rpc-reply> tag elements (here, objects for which the identifier tag element is called <name>). For information about the attributes in the opening <configuration> tag, see Specifying 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 Requesting Multiple Configuration Elements Simultaneously Using NETCONF.

The following example shows how to request the identifier for each BGP neighbor configured at the [edit protocols bgp group next-door-neighbors] hierarchy level in the candidate configuration.