Since I finished my series of articles on the CCIE, I thought I would kick off a new series on my current area of focus: network programmability. The past year at Cisco, programmability and automation have been my focus, first on Nexus and now on Catalyst switches. I did do a two-part post on DCNM, a product which I am no longer covering, but it’s well worth a read if you are interested in learning the value of automation.
One thing I’ve noticed about this topic is that many of the people working on and explaining programmability have a background in software engineering. I, on the other hand, approach the subject from the perspective of a network engineer. I did do some programming when I was younger, in Pascal (showing my age here) and C. I also did a tiny bit of C++ but not enough to really get comfortable with object-oriented programming. Regardless, I left programming (now known as “coding”) behind for a long time, and the field has advanced in the meantime. Because of this, when I explain these concepts I don’t bring the assumptions of a professional software engineer, but assume you, the reader, know nothing either.
Thus, it seems logical that in starting out this series, I need to explain what exactly programmability means in the context of network engineering, and what it means to do something programmatically.
Programmability simply means the capacity for a network device to be configured and managed by a computer program, as opposed to being configured and managed directly by humans. This is a broad definition, but technically using an interface like Expect (really just CLI) or SNMP qualifies as a type of programmability. Thus, we can qualify this by saying that programmability in today’s world includes the design of interfaces that are optimized for machine-to-machine control.
To manage a network device programmatically really just means using a computer program to control that network device. However, when we consider a computer program, it has certain characteristics over and above simply controlling a device. Essential to programming is the design of control structures that make decisions based on certain pieces of information.
Thus, we could use NETCONF to simply push configuration to a router or switch, but this isn’t the most optimal reason to use it. It would be a far more effective use of NETCONF if we read some piece of data from the device (say interface errors) and took an action based on that data (say, shutting the interface down when the counters got too high.) The other advantage of programmability is the ability to tie together multiple systems. For example, we could read a device inventory out of APIC-EM, and then push config to devices based on the device type. In other words, the decision-making capability of programmability is most important.
Network programmability encompasses a number of technologies:
- Day 0 technologies to bring network devices up with an appropriate software version and configuration, with little to no human intervention. Examples: ZTP, PoAP, PnP.
- Technologies to push and read configuration and operational data from devices. Examples: SNMP, NETCONF.
- Automation systems such as Puppet, Chef, and Ansible, which are not strictly programming languages, but allow for configuration of numerous devices based on the role of the device.
- The use of external programming languages, such as Ruby and Python, to interact with network devices.
- The use of on-box programming technologies, such as on-box Python and EEM, to control network devices.
In this series of articles we will cover all of these topics as well as the mysteries of data models, YANG, YAML, JSON, XML, etc., all within the context of network engineering. I know when I first encountered YANG and data models, I was quite confused and I hope I clear up some of this confusion.