Experimenting with NETCONF connector in OpenDaylight

July 29, 2015 by opendaylight 1 Comment

netconf-managing-routersOn the southbound, OpenDaylight has support for both NETCONF and OpenFlow for managing underlying devices. This allows your applications to manage both traditional devices with in-built control planes and the OpenFlow-enabled devices with decoupled control planes. End-to-end control and orchestration is, thus, easily achieved using a single platform.

1. Setup

In this post we get an understanding of the NETCONF support through a simple experiment with netopeer‘s NETCONF server packaged as a Docker image. Here are steps to get a hands-on experience into using NETCONF:

Step 1: Install Docker and netopeer image.

Step 2: Spin up simulated router instances. We now spin up two simulated router instances ( router1 and router2) that can be configured over NETCONF. (Assuming you have the SDNHub_OpenDaylight_Tutorial folder cloned)

These two simulated routers use the following custom YANG model to model some basic configurations of typical routers.

Step 3: Start OpenDaylight and register the two NETCONF devices. In this example, we use the pre-compiled OpenDaylight in the tutorial VM. Ensure that you install the odl-netconf-connector-all feature

After waiting about 30 secs, register the two NETCONF-enabled routers with OpenDaylight using shell scripts provided. Ensure that the IP address below is updated to what was printed by the spawn_router script above.

2. Using RESTconf to manage the devices

Now that you have registered the two NETCONF speakers, you will be able to get and edit configurations, and perform RPC calls from the controller

  • You can see all the YANG models support by that device at this location.
  • For instance, for each router we spawned, you see the following capability in that list:
  • This works only if your device has support for ietf-netconf-monitoring, wherein devices export their capabilities or modules to the NETCONF client.
  • If you are attempting to manage a device that does not support ietf-netconf-monitoring, there are other ways to add the YANG models directly at the controller.

We can start posting configurations from the OpenDaylight controller to the NETCONF servers in the routers using the router YANG model shown above. For instance, we can inject configurations to router1 using RESTCONF as follows:

Visit this page after making the above cUrl call to verify that the configuration was added.

Alternatively, you can use netopeer-cli (which is a NETCONF client) to verify the same data as follows:

As you can see, our RESTconf operation pushed configuration from the OpenDaylight controller to the data store of the device’s NETCONF server. The traditional control plane will, then, pass those configurations to the routing protocols within.

You can further experiment with this environment and push other configurations (like BGP and OSPF) for these two routers. Here is an example of how you can configure OSPF and BGP parameters (assuming all the interface IP are assigned prior to this):

Here is a postman collections file with a few REST calls in case you want to add or get configurations.

3. Developing a NETCONF application in Java

Within the tutorial project, we have a Java application that uses the OpenDaylight NETCONF connector to program configurations to the underlying device. This is to illustrate the type of automation possible within the JVM. This is also a way to logically centralize state pertaining all types of devices, both OpenFlow-based devices and legacy ones, allowing for backward compatibility.

To enable this application, you will have to install the appropriate feature in the Karaf console, prior to registering the NETCONF devices using the “register_netconf_device.sh” script.

Now run “register_netconf_device.sh” in another terminal for router1. That in turn will print the following output in the console, confirming that configuration has been written to data store.

The implementation for the netconf-exercise (i.e., netconf-exercise-impl) has a helper class called MyRouterOrchestrator that inserts interface configurations when it discovers a device called router1 or router2. Visit this page for router1 after registering the device to verify that the appropriate interface configurations were added.

The basic constructs necessary for working with a NETCONF device are as follows:

The above skeleton code skips several steps to just highlight the basic constructs for mounting device configuration and editing it. Any changes made to the MD-SAL data store is passed along to the device. Similarly, when the controller boots up, any existing configuration is copied over from the device.

4. Summary

  • This post illustrates how easy it is to configure legacy routers over NETCONF, as long as you have the YANG model for that device. This can be extremely powerful as a global orchestrator that nicely integrates OpenFlow and traditional control planes.
  • Having said that, to manage different types of devices, one needs to build YANG-specific plugins or adapters to appropriately convert from high-level intent to device-specific configurations.
  • This device-specific adaptation can be avoided if device configurations share a common model, like OpenConfig, for the common denominator of configurations for a protocol.

One comment on “Experimenting with NETCONF connector in OpenDaylight

  1. on October 6, 2015

    Is there any documentation for ODL NETCONF connector anywhere?

Leave a Reply