Search code examples
opendaylightnetconf

SSH Access Netconf Server in OpenDaylight


I need to access the config subsystem (a.ka. the datastore) in OpenDaylight. I have read the user guide and know that the way to access it is via:

ssh admin@localhost -p 2830 -s netconf

or (the way I shell into it):

# netopeer2-cli
> connect --ssh --port 2830 --login admin

Once logged in, I noticed after running get-config I don't see the actual data in the subsystem.

> get-config --source=running
DATA
<network-topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
  <topology>
    <topology-id>topology-netconf</topology-id>
  </topology>
</network-topology>

In a previous project, I was running netopeer2-server and sysrepo and the data in get-config was fleshed out. I believe the reason I am seeing such little information is because the netconf-server I am looking at is the MDSAL netconf-server on port 2830. Based on the user guide, there should be another netconf-server on port 1830 that has direct access to the config subsystem.

How do I access the normal netconf-server on port 1830?

My main goal is to access the data in the full subsystem via get-config and edit the data via edit-config -- how do I do that?

My versions:

  • OpenDaylight Sodium (based off of 0.11.0)
  • netopeer2-cli v1.1.39

Solution

  • It looks like the config subsystem endpoint was deprecated back in Flourine--but the documentation has not been updated--even the latest release notes for Sodium indicate that they still maintain a CSS NETCONF server as part of their standard set of questions the dev team answers. I found this here:

    https://jira.opendaylight.org/browse/NETCONF-535

    I believe the MDSAL server is the only one available now, and it does (in its HELLO response) seem to indicate that it maintains the capabilities for all YANG-compliant modules. However, I cannot access these elements using the netopeer2-cli as the libyang parsing seems to issue a lot of errors. I suspect this is an issue related to netopeer2-cli and its requesting/parsing of the various YANG files after the initial HELLO and how it works with libyang to construct a local version of the model for the purposes of handling various NETCONF requests.