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.
Network Automation Software
What tools do you need to automate your systems and networks?
Click the link above to go directly to that section.
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 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.
At the time of writing the tools listed below are seen as the best network automation tools in use today.
If you are not sure what network automation is, please read this post first.
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.
Check out my post – What is Ansible?
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.
If you are looking for Cisco automation tools as we keep saying Ansible is the current tool of choice.
An example playbook below shows how to run a few simple commands on a Cisco router to configure SNMP
--- - hosts: ROUTERS gather_facts: false connection: local tasks: - name: Configure SNMP String on all devices ios_config: save_when: changed lines: - 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.
To learn more about how to use Ansible check out my Ansible Network Automation Course
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 are looking for free network configuration management, you can’t go wrong with Ansible Core.
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.
If you are looking for network engineer software tools, Ansible is the swiss army knife of network automation tools, if you can do it on the CLI then you can get Ansible to automate it.
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
If we had to decide on Puppet vs Ansible for network automation, we would always use Ansible for the fact it is agentless and only requires and SSH connection to the target device, which is the case for most network hardware.
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.
8. Cisco NSO – Network Services Orchestrator
Cisco NSO is free to use for non-production networks and can be downloaded from https://developer.cisco.com/site/nso/
Previously known as Tail-F the orchestrator provides a single network wide interface for all network devices and services as well as a common modeling language and data store for both services and devices.
Check out my guide: Cisco NSO Installation Guide for Ubuntu
A bonus entry to the list is NetYCE. Although not actually Open Source software NetYCE is a paid product but in January 2019 they released a free community version.
NetYCE is a network automation framework specifically developed for network engineers to build their own network automation solutions in no time without coding.
The framework is an ideal alternative to Ansible and Python if you prefer using your network engineering skills to build network automation use-cases over learning programming skills.
Check out a more in depth review of NetYCE here:
Cisco Network Automation Tools
Aside from all the open source options, Cisco are not lagging behind and have their own suite of Cisco 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)
Also mentioned earlier and probably the product that will be leading the way is Cisco Network Services Orchestrator (NSO)
If you are looking for some network automation examples using Ansible – check out my Github
Network Automation Software
Listed above are all the current network automation software tools that are being used by organisations and individuals. Just having the software is not the whole picture and you need to start to get your team to embrace network automation and once people start to accept it as the way things are done you will get the support you need to develop the solutions.
I would say yes, Ansible has the most use right now of any tool in Network Automation, mainly because of it’s ease of use and simple operation.
Nornir is a pure Python Network Automation Tool, it gives you a lot more control and granularity if you want to perform a specific task, but does require some good Python skills to operate. Ansible uses YAML to run playbooks. Both are good tools, Ansible is easier to get started with, Nornir requires some Python knowledge but is more powerful.
Check out my Nornir course
No, this is a very common question and whilst the world of Network Engineering is moving more towards the development world every day, you just need to have a good understanding of coding. You don’t need to become a developer.
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 automating your network