Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

NETCONF Monitoring

SUMMARY You can query Junos devices to retrieve NETCONF state information and supported schemas from the NETCONF server.

Junos devices support concurrent management sessions from multiple local and remote NETCONF clients. At times, you need visibility into the active NETCONF sessions on a device as well as information about NETCONF server statistics and support. Having easy access to NETCONF state information enables you to more effectively manage your network devices.

The NETCONF monitoring data model provides operational information about the NETCONF server. NETCONF clients can query a Junos device to retrieve NETCONF state information from the NETCONF server. Clients can request information for NETCONF capabilities, NETCONF sessions and statistics, configuration datastores, and supported schemas.

For more information about the NETCONF monitoring model, see RFC 6022, YANG Module for NETCONF Monitoring.

NETCONF State Information Overview

The NETCONF monitoring data model defines the NETCONF server's operational data. The netconf-state container comprises subtrees that define and include the data for the different areas of operation.

Table 1 outlines the netconf-state subtrees supported on Junos devices.

Table 1: Supported netconf-state Subtrees

netconf-state Subtree

Description

capabilities

NETCONF operations supported by the NETCONF server.

datastores

Available configuration datastores, for example, candidate or running (active), and their lock state.

schemas

Schemas supported on the device.

sessions

Active NETCONF management sessions on the device.

statistics

NETCONF server performance data.

Junos devices that support the NETCONF monitoring data model advertise this capability in the NETCONF session's capabilities exchange during session setup.

To request NETCONF state information, send a <get> request, and specify the netconf-state subtree of interest, for example, <datastores>.

When you request NETCONF state information, the server's RPC reply includes the <data> and <netconf-state> elements. These elements enclose the subtree for the requested information.

The netconf-state <sessions> and <statistics> subtrees include information about active NETCONF sessions and NETCONF server data, respectively. Table 2 outlines the supported elements returned for these filters. The <sessions> data includes per-session counters. The <statistics> data reports global counters for the NETCONF server.

Table 2: NETCONF Sessions and Statistics Data
Node Description Filters

<dropped-sessions>

Number of NETCONF sessions that were abnormally terminated.

<statistics>

<in-bad-rpcs>

Number of incorrect RPC messages received by the server.

<sessions>

<statistics>

<in-rpcs>

Number of correct RPC messages received by the server.

<sessions>

<statistics>

<in-sessions>

Number of NETCONF sessions started.

<statistics>

<login-time>

Date and time when the NETCONF session was established.

<sessions>

<netconf-start-time>

Date and time when the NETCONF server was started.

<statistics>

<out-notifications>

Number of <notification> messages sent.

<sessions>

<statistics>

<out-rpc-errors>

Number of NETCONF server RPC replies that contained an <rpc-error> element.

<sessions>

<statistics>

<session-id>

NETCONF session identifier.

<sessions>

<source-host>

IP address or hostname from which the NETCONF client connected.

<sessions>

<transport>

Transport protcol for the NETCONF session, for example, netconf-ssh.

<sessions>

<username>

Client identity authenticated by the NETCONF transport protocol.

<sessions>

Retrieve NETCONF Capabilities

A NETCONF client can retrieve the NETCONF server's capabilities. The capabilities define the operations supported by the NETCONF server. The NETCONF server advertises the supported capabilities during session setup. By default, Junos devices do not advertise supported YANG modules in the capabilities list. However, you can configure the device to include them.

To request the capabilities of the NETCONF server:

  1. (Optional) Configure the device to advertise the different supported YANG modules in the NETCONF capabilities list, if desired.
  2. In a NETCONF session, execute a <get> operation for the netconf-state/capabilities subtree.

The NETCONF server returns the <capabilities> element with the supported capabilities. The <capabilities> information is identical to that in the <hello> message exchange sent during session setup.

Retrieve Configuration Datastores

The configuration datastores are the configuration databases supported on the device. When you request information about the configuration datastores, the server also returns their lock status.

To request the list of configuration datastores supported by the NETCONF server:

  • In a NETCONF session, execute a <get> operation for the netconf-state/datastores subtree.

The NETCONF server returns the configuration datastores and their lock states. In this case, the datastores include the candidate configuration, which has a lock on it, and the running (active) configuration.

Retrieve Schemas

NETCONF clients can request the list of schemas supported on the device. By default, Junos devices return only the Junos native schemas in the supported schemas list. However, you can configure the device to include any additional supported schemas, including custom YANG modules that are installed on the device as well as standard modules, such as OpenConfig.

To request the list of supported schemas:

  1. (Optional) Configure the device to emit any additional schemas, other than the default native schemas.
    • To include schemas for custom YANG modules installed on the device, configure the retrieve-custom-yang-modules statement.

    • To include schemas for standard YANG modules, such as OpenConfig, configure the retrieve-standard-yang-modules statement.

  2. If you modified the configuration in the previous step, commit the configuration.
  3. In a NETCONF session, execute a <get> operation for the netconf-state/schemas subtree.

The device returns the list of supported schemas. The output includes the Junos native schemas. The output also include custom and standard schemas, if you configured the device to emit these schemas.

The netconf-state/schemas subtree only returns the identifiers for the supported schemas. It does not include the actual schemas. Given the identifer, you can retrieve a specific schema instance. To request a schema instance in a NETCONF session:

  • Execute the <get-schema> operation and specify the schema identifier.

    For example, the following RPC retrieves the junos-conf-access-profile schema.

The NETCONF server returns the schema in YANG format, which is the default and only supported format.

Retrieve NETCONF Session Information

NETCONF clients can request a list of the active NETCONF sessions on the device. The NETCONF server returns the active sessions along with information about each session. The returned data includes per-session counters. See Table 2 for descriptions of the output fields.

For sessions where certain values are undefined, for example, internal sessions, the default values for transport, username, and source-host are netconf-ssh, internal-user, and local-host, respectively.

To retrieve the active NETCONF sessions on the device:

  • In a NETCONF session, execute a <get> operation for the netconf-state/sessions subtree.

The NETCONF server returns the active NETCONF sessions along with the session-specific data.

Retrieve NETCONF Server Statistics

A NETCONF client can request the NETCONF server statistics for a given device. Whereas the <netconf-state> <sessions> filter returns per-session counters, the <netconf-state> <statistics> filter returns global counters for the NETCONF server. See Table 2 for descriptions of the output fields.

To request NETCONF server statistics on a device:

  • In a NETCONF session, execute a <get> operation for the netconf-state/statistics subtree.

The NETCONF server returns the global performance data for the server.