NETCONF = Expect on steroids

After the initial explosion of OpenFlow/SDN hype, a number of people made claims that OpenFlow is not the tool one can use to make SDN work, and NETCONF is commonly mentioned as an alternative (not surprisingly, considering that both Cisco IOS and Junos support it). Unfortunately, considering today’s state of NETCONF, nothing can be further from the truth.

What is NETCONF?

NETCONF (RFC 6421) is an XML-based protocol used to manage the configuration of networking equipment. It allows the management console (“manager”) to issue commands and change configuration of networking devices (“NETCONF agents”). In this respect, it’s somewhat similar to SNMP, but since it uses XML, provides a much richer set of functionality than the simple key/value pairs of SNMP.

For more details, I would strongly suggest you listen to the NETCONF Packet Pushers podcast.

What’s wrong with NETCONF?

Greg Ferro made a great analogy in the above-mentioned podcast: NETCONF is like SNMPv2/v3 (the transport protocol) and Yang (the language used to describe valid NETCONF messages) is like ASN.1 (the syntax describing SNMP variables). However, there’s a third component in the SNMP framework: a large set of standardized MIBs that are implemented by almost all networking vendors.

It’s thus possible to write a network management application using a standard MIB that would work with equipment from all vendors that decided to implement that MIB. For example, should the Hadoop developers decide to use LLDP to auto-discover the topology of the Hadoop clusters, they could rely on LLDP MIB being available in switches from most data center networking vendors.

Apart from few basic aspects of session management, no such standardized data structure exists in the NETCONF world. For example, there’s no standardized command (specified in an RFC) that you could use to get the list of interfaces, shut down an interface, or configure an IP address on an interface. The drafts are being written by the NETMOD working group, but it will take a while before they make it to the RFC status and get implemented by major vendors.

Every single vendor that graced us with a NETCONF implementation thus uses its own proprietary format within the NETCONF’s XML envelope. In most cases, the vendor-specific part of the message maps directly into existing CLI commands (in Junos case, the commands are XML-formatted because Junos uses XML internally). Could I thus write a NETCONF application that would work with Cisco IOS and Junos? Sure I could … if I’d implement a vendor-specific module for every device family I plan to support in my application.

Why would you use NETCONF?

Let’s consider the alternatives: decades ago we configured network devices over Telnet sessions using expect scripts – simple automation scripts that would specify what one needs to send to the device, and what response one should expect. You could implement the scripts with the original expect tool, or with a scripting language like Tcl or Perl.

Using a standard protocol that provides clear message delineation (expect scripts were mainly guesswork and could break with every software upgrade done on the networking devices) and error reporting (another guesswork part of the expect scripts) is evidently a much more robust solution, but it’s still too little and delivered way too slowly. What we need is a standard mechanism of configuring a multi-vendor environment, not a better wrapper around existing CLI (although the better wrapper does come handy).

8 comments:

  1. Ivan,
    I think the answer to this conundrum is already taking shape in the form of OpenStack Quantum. A network configuration abstraction layer. What you standardize on is a north bound API, and you let vendors provide their specific "plugins" for carrying out the southbound operations - which could be NETCONF, OpenFlow, expect scripts, whatever.

    ReplyDelete
    Replies
    1. Let me know when the abstractions don't suck...

      Delete
    2. Hi Brad,
      I agree with you in that Quantum is headed in the right direction architecturally. Specifically, the ability of plugins to define extension APIs is analogous to the enterprise private MIBs we all know and love for pre-standards or proprietary functionality.

      However, the currently defined 'core' APIs don't really allow granular access to the configurables on individual devices, the whole point being that the consumers of the NB API shouldn't have to twiddle bits in order to accomplish a provisioning task. So while Quantum is likely to evolve into a great abstraction layer for orchestration and compound provisioning operations, I don't really see it being terribly useful to CLI junkies and power users in the way that Expect scripting and Netconf (with direct mappings to device CLI/SNMP variables) can be.

      To my knowledge, I also don't know of anyone using Quantum outside of the Openstack (Nova Compute as the driver of the NB API) ecosystem. This is likely because Quantum is still young and not quite ready to go out on its own; worth keeping an eye on for sure.

      (Disclaimer: I work for a vendor that enthusiastically backs Openstack)

      Delete
    3. Sarwar,

      A vendor specific "plugins" for Quantum can expose additional vendor specific features and functionality not currently in the 'core' API. If those feature prove useful and commonly required, they can at some point be rolled into the 'core' Quantum API.

      Topics such as NETCONF and OpenFlow are usually relevant in discussions about orchestration and network automation. The needs of the human CLI junky has little relevance in automation. In troubleshooting, the human CLI junky will likely bypass and ignore any abstraction layers anyway and just CLI straight to the vendor switch device.

      Delete
  2. I think the analogy both with expect and with SNMP is flawed. I've written a number of scripts that utilize NetConf and it is far easier (and more reliable) to use than either SNMP or Expect.

    But you're right, there needs to be something like NETMOD.

    ReplyDelete
    Replies
    1. I agree NETCONF is way better than Expect (didn't I just say that?), but at the moment it's still CLI wrapped in XML sugarcoating. Agreed?

      I mentioned SNMP solely because it has the third component (standard MIBs).

      Delete
    2. I guess you could say that at a high-level. Digging in the details a bit, though, shows that in JUNOScript everything is XML-ized in the response. Every bit of information is enclosed in its own tags. In IOS, this is not always true. For some commands, the IOS router just takes the output of the CLI command and encapsulates the whole thing into a single set of tags. You still have to screw around with parsing (regex, etc) in your script.

      Delete
  3. ...and I'd also add that JUNOS (as seen through it's CLI and NETCONF) is data-centric (few verbs, much data) while the various versions of IOS are command-centric (many verbs, little data).

    This made it much easier to add NETCONF to JUNOS than IOS* since much transformation needs to be done.

    I'll say it again. The current (*hint*) NETCONF implementation in the IOS:es is unfortunately a major hurdle for NETCONF adoption and should be avoided for now.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.