Free Network Automation Tools
The world of network engineering is changing at a rapid pace and Network Automation Tools are now becoming essential to the operation of large and small networks.
This network automation tools list includes Ansible, Saltstack, Chef, Jenkins & Puppet. We will also be covering Git / Gitlab / Github & Python which is technically a programming language but also a very powerful network automation tool!
This list is growing continuously, but as of June 2018 the current leader in the Open Source Network Automation Tools race is Ansible
This post will provide an in-depth description of each tool, what it does and why one is better than another for different tasks. The post will end will some paid options but mainly in the devops world most tools are open source.
Anisble is an open source automation platform which was purchased by Red Hat in October 2015. It is used heavily by the server admin community to administer and deploy updates and patches to Linux servers. In the last few years it has gained a great following from the network community who are now using it to administer and automate network operations across a wide variety of platforms. Ansible is written in Python.
As of today Ansible has over 200 different network modules for vendors such as F5, Arista, Cloudengine and Junos to name a few.
Main benefits of Ansible
The main benefit of Ansible and why it is so heavily used by the network community is that it’s agentless. Ansible only requires an SSH connection to the target device to be able to manage it. Chef and Puppet require the installation of an agent on the target device which is fine for Linux servers but is near impossible for Cisco 3850 switch.
How does Ansible work?
Ansible operates by running a Playbook. This is a file that is written in Yaml which describes each task that it is going to perform and which module is going to perform it. The YAML file is human readable so even the most junior engineers can understand what a Playbook is going to go.
This is also described as self documenting the network.
An example playbook below shows how to run a few simple commands on a Cisco router to configure SNMP
- hosts: ROUTERS
- name: Configure SNMP String on all devices
- snmp-server community read_only RO
- snmp-server community read_write RW 1
- ip domain name roger.com
- snmp-server enable traps
- logging host 10.0.100.77
Even without knowing any YAML you could read this Playbook and know what it was going to do.
Ansible is open source and is free to run for as many devices as you want. The free version is called Ansible Core and is command line driven. There is also a GUI version called Ansible Tower which operates a paid license model depending on how many devices you want to automate.
There is also a version called Ansible Engine which is the core of Ansible driven by CLI but with a paid support model from RedHat.
If you want to use the GUI for Ansible there is also an open source version of Ansible Tower called Ansible AWX – this is unsupported but does give you the chance to benefit from all the features of Tower for free.
For more information please visit www.ansible.com/integrations/networks
Ansible core is driven by the command line, but if you want to drive Ansible with a GUI there is Ansible Tower, This is a paid option (you can run the trial version for free on 10 nodes) It gives you options to track plays and schedule playbook runs, you can also assign permissions to different groups of users via AD.
There is also another option with Ansible AWX which an open source version of Ansible Tower, this is the latest code and it’s what Ansible Tower is based upon, there is no support but it’a s great way to get the Ansible Tower features for free.
Puppet is another open source network automation tool that is predominantly used for server admin automation. It was released in 2005 and is written in Ruby. It’s main function is configuration management. The main difference between Puppet and Ansible is that Puppet requires an agent to be installed on the target device. This is not a problem for Linux servers but does provide a few challenges for network automation.
With Cisco Nexus switches you can install a puppet agent and utilise all the features of Puppet. However for older devices that do not support the installation of an agent there is a solution. Cisco also support a zero touch methodology to deploy the Puppet agent on bootup to start managing Cisco devices from day 1.
As of Puppet version 2.7 the Puppet Network Device system is a way to configure some network devices’ (switches, routers). This is currently limited to a subset of Cisco IOS devices, but the system could be extended with new device types.
For the moment only two aspects of a network device can be managed, interfaces and vlans.
Puppet uses its own configuration language, which was designed to be accessible to sysadmins. The Puppet language does not require much formal programming experience and its syntax was inspired by the Nagios configuration file format.
The Puppet infrastructure generally consists of one or more puppetmaster servers along with the puppet agent on each client node
Puppet nodes periodically pull definitions from the puppetmaster server to verify config against master config, whereas Ansible is only a push model.
Puppet also runs it’s own declarative language whereas Ansible is configured with Yaml.
Puppet also requires nodes certificates to be signed (manually) on the master. This gives you some confidence that the code won’t run or be executed against the servers that are not trusted (or configured).
Also you may want to run tasks every so often, Puppet agents run every 30 minutes by default confirming that the state of the check in node matches the desired config. Ansible does not have this functionality and if you wanted that you would have to look at Ansible Tower.
Whilst Puppet looks like a very good tool to manage Nexus devices, there is still some work to make it as easy to use for older network devices.
For more information check – https://puppet.com/solutions/networking-automation
Chef is similar to Puppet in terms of overall concept, there’s a master server and agents installed on managed nodes, but it differs in actual deployment. In addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the knife tool that uses SSH for deployment. Thereafter, managed nodes authenticate with the master through the use of certificates.
Configuration of Chef revolves around Git, so knowledge of how Git works is a prerequisite for Chef operation. Like Puppet, Chef is based on Ruby, so knowledge of Ruby is also required. As with Puppet, modules can be downloaded or written from scratch, and deployed to managed nodes following required configuration.
Chef uses the cooking theme with recipies for tasks, in terms of network automation you still need to get an agent onto the target device
As an example with Junos the Chef agent is supported on the same OS based devices as Puppet. The Juniper Chef module provides options for configuring (same as Puppet) – Physical interfaces, L2 switch ports, VLANs, Link aggregation groups. Similar to Puppet, for Junos operations, the Chef agent makes configuration changes under exclusive lock, and logs all commit operations. But you are limited as with Puppet to network devices that actually support having an agent installed.
Saltstack or Salt is another open source automation tool that has been predominantly used for server automation.
Salt works on a master / minion topology. The master is the controller and minions are the clients. Salt also faces the same challenges that Puppet and Chef do with installing an agent. There are some solutions to that in that the salt-minion can be installed on newer systems that run the operating system in a container e.g NX-OS or IOS-XR
There is a also a function called proxy minions that enables Salt to control devices that cannot run the standard Salt-Minion i.e Network devices. Proxy Minions are not out of the box features and if your network device is non-standard you might have to write your own interface.
There is a also a collaboration between Napalm and Salt called napalm-salt using Salt as the automation framework and Nampalm to talk to the network devices.
For companies that already use Saltstack to manage their server infrastructure it makes sense to use the same platform to manage your network.
Interesting video showing network automation with Salt and Napalm
Jenkins is another open source tool that is becoming more popular in the network automation world. Jenkins is CI/CD tool or Continuous Integration / Continuous Delivery tool.
Jenkins will monitor for example a Git repository and if some code changes i.e a developer has made an update to a build it will take that code change and start the process of deploying that code via one of tools above i.e Anisble. It can also have some testing built in to verify the correct code before making live.
The source code is mostly Java, with a few Groovy, Ruby, and Antlr files.
Jenkins is then run from a WAR standalone or as a servlet in a Java application server such as Tomcat. In either case, it produces a web user interface and accepts calls to its REST API. You configure a pipeline which defines tasks that you want to run e.g staging, verification, testing & deployment. Each one is executed one by one and you can define check points along the way.
If you really want to have an automated network you need a CI/CD tool to run day and night.
Jenkins also has the best logo of all the tools!
6. Git / Github / Gitlab
Git is a suite of tools that basically provide version control and code repositories. When you create network configurations on your laptop and what to keep track of code changes you would use a local Git repository, which would track the changes to the files. I personally use Git to keep track of the changes to my Ansible Playbooks.
This is fine for one person locally, but you want a system that you can upload and share code to. This is where Github and Gitlab come in.
Github is a website where you can define your repositories and upload your code, this code can then be shared with others who can clone or download your repository to their local machine. Within Github there two options paid and free. With the free option your code is visible to the public which is great for personal projects or code you are happy to have in the public domain. With a paid plan you are able to create private repositories.
Gitlab allows you to install a Git server within your infrastructure or within your cloud, you are then in control of the server and it’s access.
Finally in my Top 7 Network Automation Tools List I have Python. Now you are saying Python is not a tool, it is a programming language that a lot of the other tools are written in.
That is true but a network engineer armed with some good Python scripts can do a lot of good automation.
A tool is something that you use to make your job easier, and if you are a network engineer you should be learning Python as it will be a great tool for you going into the future.
Cisco Network Automation Tools
Aside from all the open source options, Cisco are not lagging behind and have their own suite of network automation tools.
For a long time there has always been Cisco Prime Infrastructure which does provide a way to automatically backup configs and push config via templates.
In the Data Center space there is Cisco Data Center Network Manager which provides an automated way to push configurations to Nexus deployments.
And also in the service provider space there is Crosswork
Which enables you to plan, implement, operate, monitor and optimize your Service Provider Network Automation and gain the mass awareness, augmented intelligence and proactive control for data driven, outcome based network automation. (Cisco’s words not mine)
Whilst there are so many Network Automation Tools to choose from, you have to decide if you want to go the Open Source route or the paid support route.
Open Source tools give you so much more flexibility as you can pretty much make them do exactly what you want, but you will need to have skilled network automation engineers on staff to run them, but I would assume if you are embracing devops then this should not be an option.
If you go for the paid options like Cisco Prime or Solarwinds etc you are limited to the functionality that is built in, but if things go wrong you do have the support.
Whatever you do, you just need to start automation your network