Use YANG Data Models to Configure Network Device with Ansible

It took years after NETCONF RFCs were published before IETF standardized YANG. It took another half-decade before they could agree on how to enable or disable an interface, set interface description, or read interface counters. A few more years passed by, and finally some vendors implemented some of the IETF or OpenConfig YANG data models (with one notable exception).

Now that we have the standardized structure, it’s easy to build automated multi-vendor networks, right? Not so fast…

Ruben Tripiana decided to use NETCONF and IETF or vendor-specific data models in the configure network devices part of his Building Network Automation Solutions hands-on project. Here’s a short summary of what he found out (and what I learned while chatting with him on the course Slack channel):

  • He used IETF data model to configure interfaces, and Cisco’s proprietary data model to enable BFD;
  • Similarly, he used IETF BGP data model to configure neighbors, and Cisco’s proprietary one to configure route maps.

Long story short: seamless multi-vendor network device configuration is still a pipe dream. You’re able to configure some aspects using standard data models, and have to use vendor’s data models (or text-based configuration) for the rest of your needs.

  • Ansible has netconf_config module, which allows you to configure devices using XML documents, but not to read current configuration or operational data.
  • You have to pass valid XML document (text) to the netconf_config module. In the ideal world you’d get that XML document from some internal data structure. In real life you carefully craft it as a Jinja2 template.

Isn’t this wonderful new automated world of NETCONF/YANG/APIs beautiful? Maybe it’s just me, but I see little difference from using Jinja2 templates to create vendor-specific text configurations.

Before you write an angry comment telling me what an idiot I am – I’m all for multi-vendor interoperability, having a standard way of receiving error messages from devices, and using data models. However, based on past 30 years of experience in various areas of IT I remain highly skeptical about true multi-vendor data models. Also, what we can do today is almost no better than what we’ve been doing a decade or two ago.


  1. Spot on Ivan! So many gaps in vendor's (at least Cisco's) standard models this isn't quite worth it just yet for me.

    I think said vendors are very incentived to catch up now because this is now table staged for any Enterprise, SP, or any forward thinking midmarket entity.
    1. Hi there, you mention vendor's standard models. Where can I reference them? I'd also be interested to understand how you've assessed the quality of these models. This is not a hostile assessment of you're statement, I'm genuinely interested in how you came to this conclusion....
  2. haha! I fully understand your skepticism... it was... let's say a bit of a painful to build such little piece... but I guess it was either my stubbornness or my naiveness, or maybe both =) .....
  3. Thanks for noting powerful tools with lack of standards is not a giant leap forward. I see it as added complexity for little real gain. Wish it were not that way.
    1. I would disagree on "little real gain". We do get:

      * Consistent configuration mechanism
      * Consistent error reporting
      * Defined data models (so we know in advance what can be configured)
      * Data models that can be parsed directly into Python code

      In any case, there's not much difference between network device configurations and SQL dialects. Those guys couldn't even agree on how to limit the number of results returned by a SELECT query ;) - see
  4. The Idea of a vendor neutral structure for receiving/configuring data is amazing.
    Pretty sad that the focus has been put more on the vendor specific YANG structures which takes the real value away imho. For all the vendors, i truly hope that you/they start putting more emphasize on the IETF and open standard structures.

Add comment