by Martin Bugáň | Leave us your feedback on this post!

You can simulate hundreds or thousands of NETCONF devices within your development or CI/CD. We are of course talking about our lighty NETCONF Simulator, which is now available on GitHub! This tool is free & open-source, while based on OpenDaylight’s state-of-art NETCONF implementation.

We have recently finished the implementation of get-schema RPC from NETCONF Monitoring, which is based on the RFC 6022 by the IETF and brings users a missing monitoring possibility for NETCONF devices.

Download NETCONF Device Simulator (from GitHub)

Let us know, what NETCONF device you would like to simulate!

What is a get-schema

Part of NETCONF Monitoring features is get-schema RPC, which allows the controller to download schemas from the NETCONF device to the controller, so they don’t have to be added manually.

In the points, one after another, the process of device connection looks like this (when controller and device are started):

1. Connection between NETCONF device and controller is established
2. When established and hello message capabilities exchanged, the controller requests a list of available models from the NETCONF device
3. When NETCONF device supports this feature, it sends its models to the controller
4. Controller then processes those models and builts schema context

In a more technical perspective, here is the process of connecting devices:

1. SSH connection from the controller to the NETCONF device is established
2. NETCONF device sends a hello message with its capabilities
3. Controller sends hello message with its capabilities
4. Controller requests (gets) a list of available schemas (models) from the NETCONF device datastore (ietf-netconf-monitoring:netconf-state/schemas)
5. NETCONF device sends a list of available schemas to the controller
6. controller goes through this list, download each model via get-schema RPC, and stores them in the cache/schema directory
7. Schema context is built in the controller from models in the cache/schema directory

How does the feature work in an enabled device?

In the device, there is a monitoring flag that can be set up with EnabledNetconfMonitoring(boolean) method. The feature is enabled by default. If the flag is enabled, when the device is built and then started, the device’s operational datastore is populated with schemas from the device’s schemaContext.

In our device, we use NetconfDevice implementation which is built with NetconfDeviceBuilder pattern. This feature is by default enabled and can be disabled by calling with NetconfMonitoringEnabled(false) on the NetconfDeviceBuilder, which sets a flag that netconf-monitoring will be enabled.

When the build() command is called on device builder, if that flag is set, the netconf-monitoring model is added to the device and is created NetconfDeviceImpl instance with a monitoring flag from the builder. Then, when the device is started, prepareSchemasForNetconfMonitoring is called if monitoring is enabled and the datastore is populated with schemas, which are then stored in the netconf-state/schemas path.

It is done via write transaction, where each module and submodule in the device’s schema context is converted to a schema and written into a map with schema key (if the map doesn’t already contain a schema with a given key) When the device is then connected to the controller, get-schema RPC will ask for each of these schemas in netconf-state/schemas path and download them to the cache/schema directory.

What is the purpose of the get-schema?

It helps to automate the device connection process. When a new device is connected, there is no need to manually find and add all models that the device supports in its capabilities, to the controller, but those are downloaded from the device by the controller.

[Example 1] NETCONF Monitoring schemas on our Toaster simulator device

To get a list of all schemas, it is needed to send a get request with a specified netconf-state/schemas path.

Get request for netconf-state/schemas:

<rpc message-id="nss1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <get>
                <filter type="subtree">
                    <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
                        <schemas/>
                    </netconf-state>
                </filter>
            </get>
        </rpc>
        ]]>]]>

[Example 2] netconf-state/schemas path in datastore, after get request:

This is an example of a reply with schemas stored in the data store (albeit a little shortened). Reply for a get netconf-state/schemas request:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
      <rpc-reply message-id="nss1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <data>
              <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
                  <schemas>
                      <schema>
                          <identifier>toaster</identifier>
                          <version>2009-11-20</version>
                          <format>yang</format>
                          <namespace>http://netconfcentral.org/ns/toaster</namespace>
                          <location>NETCONF</location>
                      </schema>
                      ... all schemas here
                  </schemas>
              </netconf-state>
          </data>
      </rpc-reply>

[Example 3] get-schema RPC

To get a particular schema with its content in YANG format, the following RPC is sent – an example of getting toaster schema, with revision version 2009-11-20. XML RPC request:

<rpc message-id="gs1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
        <identifier>toaster</identifier>
        <version>2009-11-20</version>
        <format>YANG</format>
    </get-schema>
</rpc>
]]>]]>

In reply, there is a YANG module schema of the requested toaster schema (again, shortened). XML get-schema RPC reply:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="gs1">
     <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
         module toaster {

             yang-version 1;

             namespace
             "http://netconfcentral.org/ns/toaster";

             prefix toast;

             organization "Netconf Central";

             contact
             "Andy Bierman <andy@netconfcentral.org>;";

             description
             "YANG version of the TOASTER-MIB.";

             revision "2009-11-20" {
             description
                 "Toaster module in progress.";
             }

             ... contents of Toaster YANG model
             
         }  // module toaster
     </data>
 </rpc-reply>