Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Requesting Configuration Information

 

To request information about a configuration on a C Series Controller, a client application encloses the <get-config>, <source>, and <filter> tag elements in an <rpc> tag element. By including the appropriate child tag element in the <source> tag element, the client application requests information from either the candidate or active configuration. By including the appropriate child tag elements in the <filter> tag element, the application can request the entire configuration or portions of it:

The type="subtree" attribute in the opening <filter> tag indicates that the client application is using XML tag elements to represent the configuration elements about which it is requesting information. For information about the syntax used within the <filter> tag element to represent elements, see Specifying the Scope of Configuration Information to Return.

Note

If the client application locks the candidate configuration before making requests, it needs to unlock the configuration after making its read requests. Other users and applications cannot change the configuration while it remains locked. For more information, see Locking and Unlocking the Candidate Configuration.

The NETCONF server encloses its reply in <configuration>, <data>, and <rpc-reply> tag elements. It includes attributes in the opening <configuration> tag that indicate the XML namespace for the enclosed tag elements and when the configuration was last changed or committed. For information about the attributes, see Requesting Information from the Candidate Configuration.

If an XML tag element is returned within an <undocumented> tag element, the corresponding configuration element is not documented in the SRC software configuration guides or officially supported by Juniper Networks. Most often, the enclosed element is used for debugging only by Juniper Networks personnel. In a smaller number of cases, the element is no longer supported or has been moved to another area of the configuration hierarchy, but appears in the current location for backward compatibility.

Client applications can also request other configuration-related information.

The following sections describe how a client application specifies the source and scope of configuration information returned by the NETCONF server:

Requesting Information from the Candidate Configuration

Requesting Information from the Candidate Configuration

To request information from the candidate configuration, a client application includes the <source> tag element and <candidate/> tag in <rpc> and <get-config> tag elements:

Note

If requesting the entire configuration, the application omits the <filter> tag element. For information about the <filter> tag element, see Specifying the Scope of Configuration Information to Return.

The NETCONF server encloses its reply in <configuration>, <data>, and <rpc-reply> tag elements. In the opening <configuration> tag, it includes the xmlns attribute to specify the namespace for the enclosed tag elements.

When returning information from the candidate configuration, the NETCONF server also includes attributes that indicate when the configuration last changed (they appear on multiple lines here only for legibility):

sdx:changed-localtime represents the time of the last change as the date and time in the C Series Controller’s local time zone.

sdx:changed-seconds represents the time of the last change as the number of seconds since midnight on 1 January 1970.

Specifying the Scope of Configuration Information to Return

Specifying the Scope of Configuration Information to Return

By including the appropriate child tag elements in the <filter> tag element within the <rpc> and <get-config> tag elements, a client application can request the entire configuration or portions of it:

For information about requesting different amounts of configuration information, see the following sections:

Requesting the Complete Configuration

Requesting the Complete Configuration

To request the entire candidate configuration, a client application encloses <get-config> and <source> tag elements and the <candidate/> tag in an <rpc> tag element:

The NETCONF server encloses its reply in <configuration>, <data>, and <rpc-reply> tag elements. For information about the attributes in the opening <configuration> tag, see Requesting Information from the Candidate Configuration.

Requesting a Hierarchy Level or Container Object Without an Identifier

Requesting a Hierarchy Level or Container Object Without an Identifier

To request complete information about all child configuration elements at a hierarchy level or in a container object that does not have an identifier, a client application emits a <filter> tag element that encloses the tag elements representing all levels in the configuration hierarchy from the root (represented by the <configuration> tag element) down to the immediate parent level of the level or container object, which is represented by an empty tag. The entire request is enclosed in an <rpc> tag element:

For information about the <source> tag element, see Requesting Information from the Candidate Configuration.

The NETCONF server returns the requested section of the configuration in <data> and <rpc-reply> tag elements. For information about the attributes in the opening <configuration> tag, see Requesting Information from the Candidate Configuration.

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.

The following example shows how to request the contents of the [edit system login] hierarchy level in the candidate configuration.

Client Application

NETCONF Server

<rpc>

  <get-config>

    <source>

      <candidate/>

    </source>

    <filter>

      <configuration>

        <system>

          <login/>

        </system>

      </configuration>

    </filter>

  </get-config>

</rpc>



]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >

  <data>

    <configuration xmlns=”URL” \

        sdx:changed-seconds="seconds" \

        sdx:changed-localtime="timestamp">

      <system>

        <login>

          <user>

            <name>barbara</name>

            <full-name>Barbara Anderson</full-name>

            <class>super-user</class>

            <uid>632</uid>

          </user>

          <!-- other child tag elements of <login> -->

        </login>

      </system>

    </configuration>

  </data>

</rpc-reply>

]]>]]>

Requesting All Configuration Objects of a Specified Type

Requesting All Configuration Objects of a Specified Type

To request complete information about all configuration objects of a specified type in a hierarchy level, a client application emits a <filter> tag element that encloses the tag elements representing all levels in the configuration hierarchy from the root (represented by the <configuration> tag element) down to the immediate parent level for the object type. An empty tag represents the requested object type. The entire request is enclosed in an <rpc> tag element:

For information about the <source> tag element, see Requesting Information from the Candidate Configuration.

This type of request is useful when the object’s parent hierarchy level has more than one type of child object. If the requested object is the only child type that can occur in its parent hierarchy level, then this type of request yields the same output as a request for the complete parent hierarchy, which is described in Requesting a Hierarchy Level or Container Object Without an Identifier.

The NETCONF server returns the requested objects in <data> and <rpc-reply> tag elements. For information about the attributes in the opening <configuration> tag, see Requesting Information from the Candidate Configuration.

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.

The following example shows how to request complete information about all radius-server objects at the [edit system] hierarchy level in the candidate configuration.

Client Application

NETCONF Server

<rpc>

  <get-config>

    <source>

      <candidate/>

    </source>

    <filter>

      <configuration>

        <system>

          <radius-server/>

        </system>

      </configuration>

    </filter>

  </get-config>

</rpc>

]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >

  <data>

    <configuration xmlns=”URL” \

        sdx:changed-seconds="seconds" \

        sdx:changed-localtime="timestamp">

      <system>

        <radius-server>

          <address>10.25.34.166</address>

          <port>1812</port>

          <secret>$9$Pf3900REcr/9t...</secret>

          <timeout>5</timeout>

          <retry>3</retry>

        </radius-server>

        <radius-server>

          <address>10.25.6.204</address>

          <port>1812</port>

          <secret>$9$K5Kvxd2gJZUi-d...</secret>

          <timeout>5</timeout>

          <retry>3</retry>

        </radius-server>

      </system>

    </configuration>

  </data>

</rpc-reply>

]]>]]>

Requesting Identifiers for Configuration Objects of a Specified Type

Requesting Identifiers for Configuration Objects of a Specified Type

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 Requesting Information from the Candidate Configuration.

Note

It is not possible to 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.

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 Requesting Information from the Candidate Configuration.

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.

The following example shows how to request the identifier for each file configured at the [edit system syslog file] hierarchy level in the candidate configuration.

Client Application

NETCONF Server

<rpc>

  <get-config>

    <source>

      <candidate/>

    </source>

    <filter>

      <configuration>

        <system>

          <syslog>

            <file/>

          </syslog>

        </system>

      </configuration>

    </filter>

  </get-config>

</rpc>

]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >

  <data>

    <configuration xmlns=”URL” \

        sdx:changed-seconds="seconds" \

        sdx:changed-localtime="timestamp">

      <system>

        <syslog>

          <file>

            <name>file1</name>

            <name>file2</name>

          </file>

        </syslog>

      </system>

    </configuration>

  </data>

</rpc-reply>

]]>]]>

Requesting One Configuration Object

Requesting One Configuration Object

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 SRC XML API Configuration Reference. The entire request is enclosed in an <rpc> tag element:

For information about the <source> tag element, see Requesting Information from the Candidate Configuration.

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 Information from the Candidate Configuration.

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.

The following example shows how to request the contents of the user called barbara, which is at the [edit system login user] hierarchy level in the candidate configuration. To specify the desired object, the client application emits the <name>barbara</name> identifier tag element as the innermost tag element.

Client Application

NETCONF Server

<rpc>

  <get-config>

    <source>

      <candidate/>

    </source>

    <filter>

      <configuration>

        <system>

          <login>

            <user>

              <name>barbara</name>

            </user>

          </login>

        </system>

      </configuration>

    </filter>

  </get-config>

</rpc>

]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >

  <data>

    <configuration xmlns=”URL” \

        sdx:changed-seconds="seconds" \

        sdx:changed-localtime="timestamp">

      <system>

        <login>

          <user>

            <name>barbara</name>

            <full-name>Barbara Anderson</full-name>

            <class>super-user</class>

            <uid>632</uid>

          </user>

          <!-- other child tag elements of <login> -->

        </login>

      </system>

    </configuration>

  </data>

</rpc-reply>

]]>]]>

Requesting Specific Child Tags for a Configuration Object

Requesting Specific Child Tags for a Configuration Object

To request specific child tag elements for 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 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. To represent the child tag elements to return, it emits each one as an empty tag. The entire request is enclosed in an <rpc> tag element:

For information about the <source> tag element, see Requesting Information from the Candidate Configuration.

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 Requesting Information from the Candidate Configuration.

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.

The following example shows how to request only the address of the next-hop router for the 192.168.5.0/24 route at the [edit routing-options static route] hierarchy level in the candidate configuration.

Client Application

NETCONF Server

<rpc>

  <get-config>

    <source>

      <candidate/>

    </source>

    <filter>

      <configuration>

        <routing-options>

          <static>

            <route>

              <destination>192.168.5.0/24</destination>

              <next-hop/>

            </route>

          </static>

        </routing-options>

      </configuration>

    </filter>

  </get-config>

</rpc>

]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >

  <data>

    <configuration xmlns=”URL” \

        sdx:changed-seconds="seconds" \

        sdx:changed-localtime="timestamp">

      <routing-options>

        <static>

          <route>

            <destination>192.168.5.0/24</destination>

            <next-hop>192.168.71.254</next-hop>

          </route>

        </static>

      </routing-options>

    </configuration>

  </data>

</rpc-reply>

]]>]]>

Requesting Multiple Configuration Elements Simultaneously

Requesting Multiple Configuration Elements Simultaneously

Within a <get-config> tag element, a client application can request multiple configuration elements of the same type or different types. The request includes only one <filter> and <configuration> tag element. (The NETCONF server returns an error if there is more than one of each.)

If two requested objects have the same parent hierarchy level, the client can either include both requests within one parent tag element, or repeat the parent tag element for each request. For example, at the [edit system] hierarchy level the client can request the list of configured services and the identifier tag element for RADIUS servers in either of the following two ways:

The client can combine requests for any of the following types of information: