Specify the Source for Configuration Information Requests in a Junos XML Protocol Session
In a Junos XML protocol session with a device running Junos
OS, a client application uses the <get-configuration> tag element to request configuration data from the device. A client
application can request information from the candidate configuration,
the active configuration (that is, the one most recently committed
on the device), or from an open instance of the ephemeral configuration
database.
The client application can instruct the device to return
configuration information from either the candidate configuration
or the active configuration by setting the database attribute to the appropriate value. To request information from
the candidate configuration, a client application includes the <get-configuration> tag element and either includes
the database="candidate" attribute or omits
the attribute completely. The Junos XML protocol server returns Junos
XML-tagged output by default, except when the compare attribute is included.
<rpc>
<get-configuration/>
<!-- OR -->
<get-configuration>
<!-- tag elements for the configuration elements to return -->
</get-configuration>
</rpc>To request information from the active configuration,
a client application includes the <get-configuration> tag element with the database="committed" attribute enclosed within the <rpc> element.
<rpc>
<get-configuration database="committed"/>
<!-- OR -->
<get-configuration database="committed">
<!-- tag elements for the configuration elements to return -->
</get-configuration>
</rpc>For information about the tag elements to enclose in the <get-configuration> tag element, see Specifying the Scope of Configuration Data to Return
in a Junos XML Protocol Session.
Starting in Junos
OS Release 13.1, when a logical system user requests the entire logical
system configuration using the <get-configuration> operation,
the RPC reply includes the <configuration> root tag. Prior to Junos OS Release 13.1, the <configuration> root tag was omitted.
To request information from a specific instance of the
ephemeral configuration database, a client application first opens
the ephemeral instance using the <open-configuration> operation with the appropriate child tags.
<rpc>
<!-- Default instance -->
<open-configuration>
<ephemeral/>
</open-configuration>
<!-- Named instance -->
<open-configuration>
<ephemeral-instance>instance-name</ephemeral-instance>
</open-configuration>
</rpc>
While the ephemeral instance is open, the client application
requests information from that instance by using the <get-configuration> operation. After all operations
on the ephemeral instance are complete, the client application closes
the instance with the <close-configuration/> operation.
<rpc>
<get-configuration/>
<!-- OR -->
<get-configuration>
<!-- tag elements for the configuration elements to return -->
</get-configuration>
</rpc>
<rpc>
<close-configuration/>
</rpc>The Junos XML protocol server encloses its reply in the <rpc-reply> tag element. Within the <rpc-reply> element, the configuration data for
the requested configuration is enclosed within the <configuration> element for Junos XML-tagged output, the <configuration-text> element for formatted ASCII output, the <configuration-set> element for configuration mode set commands, or the <configuration-json> element for configuration data
represented using JavaScript Object Notation (JSON).
When returning information from the candidate configuration
or from an instance of the ephemeral configuration database, the output
includes information about when the configuration was last changed.
When displaying the configuration as Junos XML tag elements, the Junos
XML protocol server includes this information as attributes in the
opening <configuration> tag (they appear
on multiple lines here only for legibility).
<rpc-reply xmlns:junos="URL">
<configuration junos:changed-seconds="seconds" \
junos:changed-localtime="YYYY-MM-DD hh:mm:ss TZ">
<!-- Junos XML tag elements representing configuration elements -->
</configuration>
</rpc-reply>
junos:changed-localtime represents
the time of the last change as the date and time in the device’s
local time zone.
junos:changed-seconds represents
the time of the last change as the number of seconds since midnight
on 1 January 1970.
When returning information from the active configuration, the
output includes information about when the configuration was last
committed. When displaying the configuration as Junos XML tag elements,
the Junos XML protocol server includes this information as attributes
in the opening <configuration> tag (they
appear on multiple lines here only for legibility).
<rpc-reply xmlns:junos="URL">
<configuration junos:commit-seconds="seconds" \
junos:commit-localtime="YYYY-MM-DD hh:mm:ss TZ" \
junos:commit-user="username">
<!-- Junos XML tag elements representing configuration elements -->
</configuration>
</rpc-reply>
junos:commit-localtime represents
the commit time as the date and time in the device’s local time
zone.
junos:commit-seconds represents the
commit time as the number of seconds since midnight on 1 January 1970.
junos:commit-user specifies the Junos
OS username of the user who requested the commit operation.
The database attribute in
the application’s request can be combined with one or more of
the following attributes in the <get-configuration/> tag or opening <get-configuration> tag:
changed, which is described in Requesting Change Indicators for Configuration Elements Using the Junos XML Protocolcommit-scripts, which is described in Requesting Commit-Script-Style XML Configuration Data Using the Junos XML Protocolcompare, which is described in Comparing the Active or Candidate Configuration to a Prior Version Using the Junos XML Protocolformat, which is described in Specifying the Output Format for Configuration Data in a Junos XML Protocol Sessioninheritand optionallygroupsandinterface-ranges, which are described in Specifying the Output Format for Configuration Groups and Interface Ranges Using the Junos XML Protocol
The application can also include the database attribute after requesting an indicator for identifiers (as described
in Requesting Identifier Indicators for
Configuration Elements Using the Junos XML Protocol).
The following example shows how to request the entire committed configuration. In actual output, the Junos-version variable is replaced by a value such as 20.4R1 for the initial version of Junos OS Release 20.4.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
<get-configuration> operation,
the RPC reply includes the <configuration> root tag.