Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

Symbols  A  C  D  E  I  J  K  L  M  N  O  P  R  S  T  W  X

 

Symbols

<bad-element> tag (NETCONF)    
usage guidelines
<candidate/> tag (NETCONF)    
usage guidelines    
changing configuration
locking configuration
replacing entire configuration
requesting configuration
unlocking configuration
<capabilities> tag (NETCONF)    
usage guidelines
<capability> tag (NETCONF)    
usage guidelines
<close-session/> tag (NETCONF)    
usage guidelines
<commit> tag (NETCONF)    
usage guidelines    
regular commit
<config> tag (NETCONF)    
usage guidelines
<configuration> tag (SRC XML)
<copy-config> tag (NETCONF)    
usage guidelines
<data> tag (NETCONF)    
usage guidelines
<default-operation> tag (NETCONF)    
usage guidelines    
deleting configuration
general
replacing configuration
<discard-changes> tag (NETCONF)    
usage guidelines
<edit-config> tag (NETCONF)    
usage guidelines
<error-info> tag (NETCONF)    
usage guidelines
<error-message> tag (NETCONF)    
usage guidelines
<error-path> tag (NETCONF)    
usage guidelines
<error-severity> tag (NETCONF)    
usage guidelines
<filter> tag (NETCONF)    
usage guidelines
<get-config> tag (NETCONF)    
usage guidelines    
all objects of type
complete configuration
hierarchy level
identifiers only
multiple elements
overview
single object
specific children
<hello> tag (NETCONF)    
usage guidelines
<kill-session> tag (NETCONF)    
usage guidelines
<lock> tag (NETCONF)    
usage guidelines
<ok/> tag (NETCONF)    
usage guidelines
<output> tag (SRC XML)
<rpc-error> tag (NETCONF)    
usage guidelines
<rpc-reply> tag (NETCONF)    
usage guidelines
<rpc> tag (NETCONF)    
usage guidelines
<session-id> tag (NETCONF)    
usage guidelines    
initializing session
terminating session
<source> tag (NETCONF)    
usage guidelines    
replacing entire configuration
requesting configuration
<target> tag (NETCONF)    
usage guidelines    
changing configuration
locking configuration
replacing entire configuration
unlocking configuration
<unlock> tag (NETCONF)    
usage guidelines
<url> tag (NETCONF)    
usage guidelines    
changing configuration
replacing entire configuration
]]>]]> character sequence (NETCONF)    
usage guidelines
 

A

access    
protocols for NETCONF
attributes    
NETCONF tags    
For usage guidelines, see names of individual attributes
in <rpc> echoed in <rpc-reply>
SRC XML tags    
For usage guidelines, see names of individual attributes
authentication    
NETCONF
 

C

child tags (XML).     See tags (XML)    
commands    
mapping options to SRC XML tags    
fixed-form
variable-form
comments    
NETCONF and XML
compatibility    
between NETCONF server and application
configuration    
changing    
NETCONF (overview)
committing    
immediately (NETCONF)
creating    
element only if new (NETCONF)
deleting    
hierarchy level (NETCONF)
multiple values from leaf (NETCONF)
object (NETCONF)
overview (NETCONF)
single option (NETCONF)
discarding changes    
NETCONF
displaying    
candidate (NETCONF)
entire (NETCONF)
hierarchy level (NETCONF)
identifiers (NETCONF)
multiple elements at once (NETCONF)
objects of specific type (NETCONF)
overview (NETCONF)
single object (NETCONF)
specific children of object (NETCONF)
loading    
as a data stream (NETCONF)
as data in a file (NETCONF)
default mode for NETCONF
locking    
NETCONF
merging current and new    
NETCONF
modifying    
NETCONF
NETCONF operations on
replacing    
entire (NETCONF)
single element (NETCONF)
rolling back to previous    
NETCONF
statements.     See configuration statements    
unlocking    
NETCONF
verifying    
NETCONF
configuration statements    
deleting    
NETCONF
mapping to Junos XML tags    
multiple options on one line
mapping to SRC XML tags    
hierarchy level or container tag
identifiers
keywords
leaf statements
multiple values for an option
conventions    
NETCONF    
for client to comply with
notice icons
text
create (NETCONF 'operation' attribute)    1
usage guidelines
customer support    1
contacting JTAC
 

D

default mode for NETCONF configuration changes
delete (NETCONF 'operation' attribute)    1
usage guidelines
display xml command    
usage guidelines
Document Object Model.     See DOM    
document type definition.     See DTD    
documentation    
comments on
DOM
DTD    
defined
separate for each SRC software module
 

E

entity references, predefined (SRC XML)
error messages    
from NETCONF server
examples, Junos XML    
mapping of configuration statement to tag    
multiple options on multiple lines
multiple options on single line
examples, NETCONF    
creating configuration elements
deleting    
fixed-form option
hierarchy level
single configuration object
value from list of multiple values
merging in new configuration data
providing configuration data    
in a file
in a stream
replacing configuration elements
requesting    
all objects of a type
identifiers only
one configuration level
one configuration object
specific children of object
session
terminating session
examples, SRC XML    
mapping of configuration statement to tag    
hierarchy levels
identifier
leaf statement with keyword and value
leaf statement with keyword only
multiple predefined values for option
multiple user-defined values for option
Extensible Markup Language.     See XML    
 

I

identifiers    
SRC XML mapping
 

J

Junos XML tags    
mapping    
configuration, multiple multioption lines
 

K

keyword in configuration statement, SRC XML mapping
 

L

leaf statement    
SRC XML mapping
 

M

manuals    
comments on
 

N

namespaces.     See XML, namespaces    
NETCONF API    
comments, treatment of
conventions
overview
server.     See NETCONF server    
session.     See NETCONF session    
tags    
For usage guidelines, see names of individual tags
white space, treatment of
NETCONF server    
classes of responses emitted
closing connection to
connecting to
error message from
establishing session with
overview
parsing output from
sending request to
verifying compatibility with application
warning from
NETCONF session    
authentication and security
brief overview
ending
establishing
example
terminating another
NETCONF tags    
For usage guidelines, see names of individual tags
notational conventions
newline character in XML tag sequences
no-change mode (NETCONF)
notice icons
 

O

operation attribute (SRC XML with NETCONF)    1
usage guidelines    
creating element
deleting element
replacing element
operational mode, CLI    
SRC XML mapping    
for requests
for responses
options in configuration statements, SRC XML mapping
output from NETCONF server, parsing
 

P

predefined entity references (SRC XML)
prerequisites    
NETCONF API
 

R

replace (NETCONF 'operation' attribute)    1
usage guidelines
replace mode (NETCONF)
request tags (XML).     See tags (XML)    
response tags (XML).     See tags (XML)    
routers    
configuration.     See configuration    
 

S

SAX (Simple API for XML)
sdx:changed-localtime attribute (SRC XML)    
usage guidelines
sdx:changed-seconds attribute (SRC XML)    
usage guidelines
security    
NETCONF session
session, NETCONF.     See NETCONF session    
Simple API for XML.     See SAX    
software versions    
compatibility between NETCONF client and server
space character in XML tag sequences
SRC XML API    
overview
predefined entity references
tags.     See SRC XML tags    
SRC XML tags    
<configuration>    1
attributes in
<output>
displaying CLI output as
mapping    
command options, fixed-form
command options, variable
configuration, hierarchy level
configuration, identifier
configuration, multivalue leaf
configuration, single-value leaf
notational conventions
ssh service    
NETCONF access protocol
support, technical     See technical support    
 

T

tags (XML)    
NETCONF    
For usage guidelines, see names of individual tags
request    
children of
defined
NETCONF
SRC XML
response    
<rpc-reply> as container for
children of
defined
NETCONF
SRC XML
SRC XML     See SRC XML tags    
white space in and around
technical support    
contacting JTAC
text conventions defined
 

W

warning    
from NETCONF server
white space in XML tag sequences
 

X

XML    
namespaces    1
defined for operational response tags
overview
tags.     See tags (XML)    
xmlns attribute    
<configuration> tag    
usage guidelines
NETCONF    
usage guidelines
SRC XML operational responses    
usage guidelines

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:


<rpc>
   <get-config>
        <source>
            <!- - tag specifying the source configuration - ->
        </source>
        <filter type="subtree">
            <!- - tag elements representing the configuration elements to return - ->
        </filter>
   </get-config>
</rpc>
]]>]]>

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.


<rpc-reply xmlns="URN" xmlns:sdx="URL”>
    <data>
        <configuration attributes>
            <!- - SRC XML tag elements representing configuration elements - ->
        </configuration>
    </data>
</rpc-reply>
]]>]]>

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

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:


<rpc>
    <get-config>
      <source>
        <candidate/>
      </source>
       <filter>
            <!- - tag elements representing the configuration elements to return - ->
       </filter>
    </get-config>
</rpc>
]]>]]>

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):


<rpc-reply xmlns="URN" xmlns:sdx="URL”>
    <data>
        <configuration xmlns="URL" sdx:changed-seconds=seconds" \
                sdx:changed-localtime="YYYY-MM-DD hh:mm:ss TZ">
            <!- - SRC XML tag elements representing the configuration - ->
        </configuration>
    </data>
</rpc-reply>
]]>]]>

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

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:


<rpc>
    <get-config>
        <source>
            <candidate/>
        </source>
        <filter>
            <!- - tag elements representing the configuration elements to return - ->
        </filter>
    </get-config>
</rpc>
]]>]]>

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

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:


<rpc>
    <get-config>
      <source>
        <candidate/>
      </source>
    </get-config>
</rpc>
]]>]]>

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.


<rpc-reply xmlns="URN "xmlns:sdx="URL”>
    <data>
        <configuration attributes>
            <!- - SRC XML tag elements representing the configuration - ->
        </configuration>
    </data>
</rpc-reply>
]]>]]>

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:


<rpc>
    <get-config>
        <source>
            <!- - tag specifying the source configuration - ->
        </source>
        <filter type="subtree">
            <configuration>
                <!- - opening tags for each parent of the requested level - ->
                <level-or-container/>
                <!- - closing tags for each parent of the requested level - ->
            </configuration>
        </filter>
    </get-config>
</rpc>
]]>]]>

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.


<rpc-reply xmlns="URN" xmlns:sdx="URL”>
    <data>
        <configuration attributes>
            <!- - opening tags for each parent of the level - ->
                <level-or-container>
                    <!- - child tag elements of the level or container - ->
                </level-or-container>
            <!- - closing tags for each parent of the level - ->
        </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.

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

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:


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

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.


<rpc-reply xmlns="URN "xmlns:sdx="URL”>
    <data>
        <configuration attributes>
            <!- - opening tags for each parent of the object type - ->
                <first-object>
                    <!- - child tag elements for the first object - ->
                </first-object>
                <second-object>
                    <!- - child tag elements for the second object - ->
                </second-object>
                <!- - additional instances of the object - ->
            <!- - closing tags for each parent of the object type - ->
        </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.

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

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:


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

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.


<rpc-reply xmlns="URN" xmlns:sdx="URL”>
    <data>
        <configuration attributes>
            <!- - opening tags for each parent of the object type - ->
                <first-object>
                    <name>identifier-for-first-object</name>
                </first-object>
                 <second-object>
                    <name>identifier-for-second-object</name>
                </second-object>
                <!- - additional objects - ->
            <!- - closing tags for each parent of the object type - ->
        </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.

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

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:


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


<rpc-reply xmlns="URN"xmlns:sdx ="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.

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

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:


<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/>
                        <!- - empty 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 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.


<rpc-reply xmlns="URN" xmlns:sdx="URL">
    <data>
        <configuration attributes>
            <!- - opening tags for each parent of the object - ->
                <object>
                    <name>identifier</name>
                    <!- - requested child tag elements - ->
                </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.

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

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:


<!- - both requests in one <system> tag element - ->
<rpc>
    <get-config>
        <source>
            <!- - tag specifying the source configuration - ->
        </source>
        <filter type="subtree">
            <configuration>
                <system>
                    <services/>
                    <radius-server>
                        <name/>
                    </radius-server>
                </system>
            </configuration>
        </filter>
    </get-config>
</rpc>
]]>]]>

<!- - separate <system> tag element for each element - ->
<rpc>
    <get-config>
        <source>
            <!- - tag specifying the source configuration - ->
        </source>
        <filter type="subtree">
            <configuration>
                <system>
                    <services/>
                </system>
                <system>
                    <radius-server>
                        <name/>
                    </radius-server>
                </system>
            </configuration>
        </filter>
    </get-config>
</rpc>
]]>]]>

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

 

Modified: 2016-06-02