Where Are the NETCONF/YANG Tools?

Jo attempted to follow the vendor Kool-Aid recommendations and use NETCONF/YANG to configure network devices. Here’s what he found (slightly edited):


IMHO, the whole NETCONF ecosystem primarily suffers from a tooling problem. Or I haven’t found the right tools yet.

ncclient is (as you mentioned somewhere else) an underdocumented mess. And that undocumented part is not even up to date. The commit hash at the bottom of the docs page is from 2020… I am amazed how so many people got it working well enough to depend on it in their applications.

The tools for browsing and inspecting YANG models are also not really there. Everything is abandoned. Cisco killed/abandoned two of its projects already. YANG Explorer is dead, and yangsuite fails to install and has outdated docs. Installation documentation talks about Python 3.6 to 3.8, the README is stuck at 3.9+ with 3.10 recommended. However, installations fail for more modern versions. All the systems I am working on ship 3.11 or newer by default now.

The Docker container was also an insane amount of pain until it worked. And of course, the code is not on GitHub; the repo there is just a dummy repo for the Docker container. All I was looking for was a nice way to display what my device supports and to display and edit the values so that I can see what I am doing in a sea of XML

There have been a couple other tools that I have found which were dead even longer.

Am I missing some nice tool? What are people actually using to get things done with NETCONF?


I had similar experiences. I tried to demonstrate how to use YANG to validate a custom network automation data model, but I failed miserably.

Kristian Larsson wrote a blog post at that time explaining how you can get the job done, so I’m guessing there must be solutions out there that work, and it’s just that our Google-Fu is failing us. pyang seems to be a tool that could accomplish some YANG-related tasks; pointers to other working, up-to-date tools would be highly appreciated.

5 comments:

  1. There's been some efforts to try and make YANG models more consumable and usable within python based automation workflows. Check out https://github.com/pydantify/pydantify - a python library which converts YANG models into pydantic models.

    Example converted models for SR Linux: https://github.com/srl-labs/pydantic-srlinux

    Still a bit experimental and it isn't able to support all features of YANG models, but there is certainly some motivation within the network automation community to try and come up with better tooling for YANG models.

  2. With the AI boom, I wrote some a tool (WIP) that uses gnmi to retrieve data from the devices (I used pygnmi https://github.com/akarneliuk/pygnmi under the hood) and yes, it was painful.

    The easiest way I found to work on it, was to find a working model and then review the structure I got from the device. So many gnmi calls just exploring what happens if I send this xpath or that xpath.

    Talking about tools, I like gNMIc https://gnmic.openconfig.net/ and the ecosystem around it. Seem solid.

    On DevNet you can also find the Cisco Metrics Search Engine https://developer.cisco.com/cmse/ which is nice, but I'm afraid the team might remove it after the lead for the tool was impacted by the last LR (if you like it or not, please share your feedback)

    If you work with IOS-XR you can find the yang navigator at https://cfnng.cisco.com/ios-xr/yang-explorer/view-data-model

    Disclaimer, I work for Cisco.

  3. While not maintained anymore, ANX (https://github.com/cisco-ie/anx) still does what's it's supposed to do: connects to the device, retrieves yang paths, can simply retrieve paths for telemetry, subscribe to paths and test Netconf payloads

  4. Rob Shakir was instrumental in getting YANG on the map in the open-source world, but the whole subject is a monster and much more than any one person can sustain alone. Network to Code put in a hell of an effort on YANG tooling with David Barroso's help a few years ago. I was super excited about it myself, but it wasn't meant to be.

    The subject feels a lot like formal methods to me. It's a powerful tool, but you have to have pretty specific problems to need it. And only a small number of the people with those specific problems will see the light and actually benefit from the tool.

    The reality is that many orgs still live in is a morass of Jinja templates and YAML masquerading as "infrastructure as code". Features always win over reliability and sustainability, and it's still hard to find an engineer who can spell t-e-s-t.

  5. We've used YGOT successfully with JunOS and IOS XE, which surprisingly, wasn’t mentioned in the list. We submit the resulting JSON payloads via RESTCONF without issues (*).

    A quick intro to YGOT: https://github.com/nleiva/go-yang-basics?tab=readme-ov-file#practical-yang-data-modeling

    (*) We use Ansible’s URI module for this. The RESTCONF specific module has a minor issue: https://github.com/ansible-collections/ansible.netcommon/issues/702

Add comment
Sidebar