Request the Committed Configuration and Device State Using NETCONF
In a NETCONF session with a device running Junos OS, to request
the most recently committed configuration and the device state information
for a routing, switching, or security platform, a client application
encloses the <get> tag in an <rpc> tag element. By including the <filter> tag element and appropriate child tag elements,
the application can request specific portions of the configuration.
If the <filter> element is omitted,
the server returns the entire configuration. The optional format attribute specifies the return format for the
configuration data.
<rpc>
<get [format="(json | set | text | xml)"]>
<filter type="subtree">
<!-- tag elements representing the configuration elements to return -->
</filter>
</get>
</rpc>
]]>]]>
The type="subtree" attribute in the
opening <filter> tag indicates that
the client application is using Junos XML tag elements to represent
the configuration elements about which it is requesting information.
The NETCONF server encloses its reply in the <rpc-reply> and <data> tag elements. Within
the <data> element, the configuration
data is enclosed in the <configuration>, <configuration-text>, <configuration-set>, or <configuration-json> element depending on the requested format, and the device information
is enclosed in the <database-status-information> element. The server 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 example:
<rpc-reply xmlns="URN" xmlns:junos="URL">
<data>
<configuration xmlns="URL" junos:changed-seconds="seconds" junos:changed-localtime="time">
<!-- configuration data -->
</configuration>
<database-status-information>
<database-status>
<user>user</user>
<terminal></terminal>
<pid>pid</pid>
<start-time junos:seconds="1416956595">2014–11–25 15:03:15 PST</start-time>
<edit-path></edit-path>
</database-status>
</database-status-information>
</data>
</rpc-reply>
]]>]]>
If there is no configuration data in the requested hierarchy,
the RPC reply contains an empty <configuration> tag inside the <data> element unless
the rfc-compliant statement is configured, in which case
the <configuration> tag is omitted.