Devops is now a widely used term. I recently read few articles on Devops in relation to Network Automation and that prompted me to do some research on this topic. In this blog, I will cover what I think comprises the Devops Networking domain and in the next series of blogs, I will try to explore individual areas in more detail. Devops allows infrastructure to be treated as a code and it makes the infrastructure programmable. The term Devops refers to a merger between Development and Operations role and it encourages Developer to look at Operations angle and Network operator to look from Developer angle. As everyone knows, automating infrastructure deployment improves efficiency, removes operator error and allows us to scale. Server automation has been present for quite some time and Network Automation is still very much in infancy stage at this point. Following article from Ivan describes Devops as a lifestyle or mindset on how infrastructure is treated rather than as tools associated with Devops.
How is Network Automation different from Server automation?
Example of Server automation task is installing a Apache webserver. Example of Network automation task is provisioning a L2vpn service. Following 2 blogs from Jeremy and David summarizes some of the key differences between Server automation and Network automation. Following are some key points as I see it:
- Server automation is more about installing applications and bringing up applications from scratch. Here, applications are mostly at device level. In Network automation, device bringup and initial device configuration is a one-time step, majority of tasks involved are provisioning services and making sure that service provisioning is working fine, this involves provisioning multiple devices at the same time.
- Majority of Networking devices still act as a closed system where hardware, control and management plane are tightly coupled. Recent white box switches allows for dis aggregation of the different planes but these hold a very small percentage of the Networking device market. This makes automating Networking applications little complex.
- Different Networking devices have different management protocols for configuration. CLI is still used predominantly and automating device configuration using CLI has a whole bunch of problems associated with it. Recent provisioning protocols like Netconf removes some of the disadvantages with CLI based provisioning as well as problems associated with SNMP. Server automation is based mostly on Linux and associated tools which are pretty standard.
- Workflow for Network Administration are tasks that are tightly coupled and modeling and automating them needs a different mindset. This is explained in this blog.
Why is Network Automation starting to happen now?
- SDN technologies centered around splitting control, data and management plane.
- Maturity of server automation tools. Some of the tools are focusing on Network automation now, there is still a long way to go here.
- Opensource projects like Opendaylight in the Networking space.
Devops categories with examples
- Configuration management – This is the biggest category that deals with automating device configurations. Some of the common tools in this category are Chef, Puppet, Ansible, CFengine. Examples of Network configuration management includes adding a new vlan, applying a qos policy with new class, creating a new l2vpn service etc.
- Monitoring – For server monitoring, there are tools like what Newrelic provides which provides analytics on software applications and server performance. For Network monitoring, there are tools like Opennnms, Nagios, Zabbix. Examples of Network monitoring are raising security alerts when there is an unauthorized access, performance monitoring etc.
- Deployment – This includes lifecycle management tools like Jenkins, revision control management like Git, automated build tools like Maven, Ant.
Networking Device configuration and management protocols
CLI is still the most commonly used interface to manage Networking devices. CLI makes it difficult to automate and newer management protocols solves some of the issues that exists with CLI. In 1 of my earlier blog, I have covered details on Netconf and Yang and how it solves some of the issues with SNMP protocol. Following are some configuration approaches:
|CLI||Can be accessed through telnet or ssh||Easier to use||Difficult to parse output(some vendors can output CLI in json/xml format)
Changes between releases
Difficult to automate
Not model driven
|SNMP||Pretty widely used for monitoring||Good for monitoring||Not transaction based
Difficult to automate for configuration
|Netconf||Protocol defined by IETF to overcome SNMP limitations for configuration.
Netconf makes RPC procedure calls for device configuration using XML encoded data and response
Easier to automate
Separates config from operational data
|Models not yet available for all configurations|
|OVSDB||Management protocol to manage Open vswitch||Model driven
Easier to automate
|Restricted to Openvswitch management currently|
|RESTConf||A REST like protocol running over HTTP for accessing data defined in YANG
Northbound protocol compared to Netconf which is southbound
Easier to automate
|New protocol, is it widely deployed?|
|OF-Config||Defined by ONF, similar to ovsdb for managing Openflow switch, uses Netconf underneath||Model driven||Restricted to Openflow switches?|
|Openflow||For adding/modifying/deleting data flows.
Used for managing data path, not configuration
Data Encoding and Modeling
Models are referred to as Schema. They describe the format of the data. Popular modelling languages are Yang and XSD. XSD is based on XML. Yang is much easier to read compared to XSD.
Data encoding formats are JSON, XML, YAML. Following link compares the different encoding formats. Depending on the type of application, particular encoding format might be more efficient and easier to parse.
In 1 of my earlier blog, I have compared JSON and XML and how to parse them.
Network Automation tools
Following article from Networkworld compares the popular Devops tools. Some of these tools are also used in Network automation. In the next set of blogs, I will explore these tools in lot more detail.
Cisco devices configuration options
I found the following picture in 1 of Cisco blog that describes the various options to configure and automate Cisco NXOS devices. I found this interesting because the same device can be now managed by different configuration and automation approaches. OnePK is Cisco SDK for managing Cisco devices using high level api abstractions. I will cover more details in a future blog.
In the next series of blogs, I will cover the following topics. Most of the topics are focussed on Cisco devices, thats mainly because I have access to Cisco devices. The concepts also apply to other Network devices as well.
- Cisco UCS automation using Python SDK
- Nexus Devices CLI parsing
- Cisco device configuration using onePK
- Cisco device configuration using Netconf
- Network device configuration templating using Jinja2 and YAML
- Ansible for Network automation
I have referred the blogs in the reference section extensively and I have also used some of their source code to try things out. Thanks to the bloggers. It looks like a lot of new work is happening in Network automation space and I am very excited about it.
Pictures used in this blog are from references.