The Case for Desired-State Configuration and YANG

I’ve been spending a while now using Solarwinds Orion configuration scripts to harmonize and update configurations on a large legacy network, so the significant limitations of the current model of network configuration are fresh on my mind.

Traditionally a lot of network equipment such as switches and routers are configured via a text file, where each line has configuration settings that get applied, with sometimes nested blocks of sub-configurations. For example, from Cisco:

Here we set the host name, then configure the first Ethernet interface with an IP address, an access list (similar to a firewall or iptables), and set the duplex and speed values, and finally turn the interface on (on some Cisco models there’s a default for an interface to be off, so turn it on you have to turn it not-off.)

Traditional methods of configuring the switch are over a serial port or SSH, or possibly by loading configuration commands in as a file via SCP, TFTP and the like. While the exact details of the complications do change based on the method used, a lot of the basic problem remains.

In my particular case one issue is that there may be random old configuration left. References to DNS servers or logging servers that no longer exist. It’s easy enough to add a server, but unless you know that there happens to an old entry (logging host 10.1.1.1) the new configuration doesn’t remove the old. So now you’re stuck writing rules to look for configuration statements of that particular format that shouldn’t be there. Certainly doable, but it adds a lot of extra complexity.

Another issue is the order of operations. A traditional example is the above access list. It’s typically a set of “permit” statements followed by an implicit (or explicit) “deny” statement. So it’s easy to either blank an access list that governs access to the switch and lock yourself out in the middle of the configuration, or apply an access list before it’s defined. Another common issue is re-addressing devices; you change the IP and subnet mask on one line, and the default gate way on another. But changing either may stop your ability to communicate until the other is applied. Once more, there are ways around it, but it still means a lot of extra complexity in planning and scripting.

You can’t just tell the switch what configuration you want it or its components have. You have to figure out what state it is currently in, and then do a lot of conditional logic to determine how to get it to the state you want it to be. There are of course additional projects to try to abstract some of that complexity, but on some level they just add yet another level of proprietary components and a black box. Some other vendors, and even some Cisco models, allow configuration sessions with roll-backs, confirms, and the ability to do more atomic applications, but that’s still short of ideal.

One attempt to fix this state of affairs is YANG and NETCONF, IETF standards for representing the state in XML or JSON and transferring the state via an RPC mechanism. This approach isn’t perfect either, and isn’t well supported by vendors. One issue is that the capabilities and peculiarities of each platform differ so much that it’s difficult to abstract away. At the very least, though, it allows for a proper desired-state configuration, which would be a fantastic step forward.

It’ll be very interesting to see whether vendors will start supporting the IETF standards or other APIs, but it’s hard for me to see that going forward we wouldn’t quickly start adding APIs for configuration instead of the old SSH and line configurations. It’s equally hard for me to see that we’ll quickly get away from this problem, considering that typical life cycle of networking gear is 10+ years in enterprise networks.