Courtesy - TechWorld
Automation is a logical next step in the SDN migration journey.
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 organisations, 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, organisations 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 organisation closer. Let's take a look at a few tools to introduce this emerging trend.
A choice of tools
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 organisation 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.
Puppet. For those not wanting to learn a programming language, there are several configuration tools popular in the server world that could be considered for network device configuration. Puppet, Chef, Ansible and Salt are most frequently named. In the network community, Puppet and Ansible have the strongest followings.
Puppet is a model-driven configuration tool that relies on a client-server architecture to deliver configurations from the controlling server to the client device being configured.
In the network world, this is a challenge in that a Puppet server needs to talk to a Puppet agent running on the client system. The requirement for an agent has ruled out many network devices, as Puppet agents simply aren't available for most network gear. The initial drive for Puppet in the network space was to extend the functionality of a tool already deployed in many enterprises to manage servers. Why use a different tool for network device configuration if Puppet is available and already being used by the organisation?
Puppet uses its own human-friendly language that allows people to describe how they want a device configured. The Puppet server translates that manifest into a configuration suitable for that device, generating a catalog. The Puppet agent polls the Puppet server periodically to retrieve any new catalogs, and make the required changes.
Puppet can be used to configure a limited number of Cisco devices, as well as certain devices from Juniper, F5, Mellanox, Arista, and presumably others. Note that "Puppet support" does not mean that every network device function will necessarily be supported by Puppet. In fact, most network engineers find that the functions they can actually configure via Puppet are limited.
Puppet is available in both open source and commercial variants.
Ansible. Similar to Puppet in overall scope, Ansible is growing in popularity in part because the design is an agentless push architecture. Ansible interacts with a remote network device via SSH, NETCONF, or other means as specified in the module written for the remote device. SSH is used frequently, although this is not something the Ansible consumer has to be overly concerned with. The module handles the work of getting the intended configuration to the remote device, whatever the means.
Network engineers describe what they would like the network configuration to be using playbooks. Playbooks are written in an easy-to-read language called YAML. Just like Puppet is limited in what specific network functions it supports, Ansible is limited by the functions described in a device's module.
In addition to its agentless nature, Ansible is gaining popularity due to reported ease of use and flexibility. Like Puppet, there are both open source and commercial flavors of Ansible.
A few other tools network engineers find useful as they look to automate their network configurations include:
Github, a free-to-use online repository for code that includes a versioning system. Of late, Github has been the go-to site to obtain code related to network configuration automation. Cisco, Arista, Juniper, Mellanox, and other network vendors maintain freely available code that supports configuration of their network devices or integration with cloud computing platforms such as OpenStack.
Vagrant, which is used to automate the creation of virtual machines. As many network devices are available as a virtual machine, Vagrant becomes useful as a way to automate the spinning up of network device VMs on VirtualBox, VMware and other hypervisors. Vagrant can also call to Ansible or Puppet to provision virtual machines once they have been instantiated.
What's next?
Network consumers interested in automating their network device configuration need to pay close attention to emerging technologies in the SDN space. APIs continue to grow in importance, providing access to SDN controllers, software modules that plug into controllers, and the network devices that sit underneath those controllers. The configuration work done by a home-grown Python program or Ansible playbook today could (and in some cases can) be done by a software defined application communicating network needs to a controller that provisions the network devices.
In fact, some SDN platforms take the network device configuration work out of the hands of human beings altogether. For example, about the only work a network engineer does on an NEC ProgrammableFlow switch is to point the switch to the controller's IP address. The rest of the configuration is done via the controller itself.Put another way, automating the configuration of network devices using tools as described in this article is truly incremental. Humans are still articulating the specifics of minutiae like VLAN numbers and routing configurations, but using better tools than the CLI or GUI to generate and install the required configuration.
Ultimately, SDN purports to take even those sorts of requirements away, allowing businesses to express their needs as policies related to security and application importance. Those abstract policy descriptions will result in software defined network device configurations that meet business needs and ensure user experience and regulatory compliance. The battle the industry is fighting now is about exactly how that complexity should be abstracted, expressed and programmatically implemented. For now, automating network configuration using powerful tools is a very good place for organisations to start.
No comments:
Post a Comment