The definition of Software Defined Networking (SDN) continues to broaden, today including functions such as configuration automation and orchestration. While these tasks aren't strictly SDN, the fact is software is used to define some aspect of the network infrastructure in both cases, so vendors have stretched the definition of SDN to bring configuration automation and orchestration platforms into the mix.
In fairness, the line gets blurry, as some modern orchestration systems use programmatic interfaces to provision the network instead of traditional configuration tools such as SSH or SNMP.
In many organizations, automating the configuration of network devices is where "SDN" is initially gaining traction. The impetus for this is straightforward: configuring network devices is woefully complicated. As vendors build more features into their routers, switches, firewalls and application delivery controllers, the command line syntax required to configure those devices becomes increasingly loaded with options and syntactic choices. Web-based GUIs are often a CLI alternative, but are slow to navigate. Web GUIs also have a way of obfuscating functions by hiding them in unlikely pages, making access to them a series of annoying clicks.
The point of commonality in traditional network device configuration is humans -- whether they use a CLI or a GUI -- and, for all our considerable merits, we aren't as competent as computers at syntax, perfectly inputting long strings of data, or remembering each step of a complex task. In my experience, humans are the No. 1 cause of network outages in the form of network engineers making an honest mistake.
Asking a human to a make a change to a production network is akin to asking a human to change the air filter on a car. While the car's engine is running. And the car is traveling down the highway at 70 miles per hour.
Can it be done? Yes. Should it be done? Hmm. Seems a little risky. And yet, organizations take exactly these risks every day, often mitigating that risk with scheduled maintenance windows. However, even those windows don't change the fact that a modern network is expected to be up 100% of the time.
For years now, server administrators have been automating repeatable and complex tasks with several different tools. Network devices are not servers, but of late, several tools from the server world are being used by the network community. These tools are addressing the issue of complexity and human error in device configuration. These tools could also be considered an incremental step on the SDN journey. While configuration automation isn't pure SDN, it certainly moves an organization closer. Let's take a look at a few tools to introduce this emerging trend.
Python. The Python programming language comes first in this list because it is widely available, popular, well-documented, and considered by many to be easy to use. In addition, some other tools that might be used for network configuration are written in Python. Therefore, Python is a flexible, multi-use tool that network engineers have been using to help them with network configuration either directly or indirectly.
The big idea behind using a programming language to create network device configurations is that a program both ensures a predictable result and can iterate through repetitive tasks. For example, let's say an organization needs to build configurations for 100 switches, that are all configured identically except for details like the hostname and perhaps VLAN membership. A program could be written in Python to generate the required configuration over and over again, substituting in the unique elements of a specific switch per iteration. Rather than an engineer building each switch by hand, copying and pasting sections of configuration and making sure the unique bits get swapped out as needed, a program does all of that work.
Python is far from the only programming language that can do this sort of work. For simple tasks as described above, all sorts of options are available. But Python has the benefit of a powerful set of libraries to access network devices and otherwise make it relatively easy to not only create configurations, but also apply those configurations.
Notably, network vendors are writing APIs for their equipment with support for Python. Cisco onePK supports Python, for example, Arista's EOS-API can be accessed with Python, and Juniper has released a "PyEZ" library to enable access to Junos devices via Python.
Jinja2. One example of Python's extensibility is Jinja2. Jinja2 is a Python library acting as a template engine. Templates are used for repeated bits of code, where perhaps just a few variables change from device to device. In network engineering, templates are useful for configuring big chunks of code that are identical on all devices of a certain class, such as a router, or for paragraphs of code in a device describing interfaces, VLANs, VRFs, and so on.
Jinja2 adds template functionality to Python, making it possible for a network engineer to iterate through all the interfaces on a device, adding unique descriptions and VLAN assignments for each one without having to manually configure each interface separately. As most data centers have a standard set of commands used on all of their interfaces, Jinja2 templates both save time and reduce potential errors when generating configuration with Python.