Chapter 13: Network Automation

Historically, a network consisted of mostly hardware with just a modicum of software involvement. Changing the topology of it involved installing and configuring new switches or blades in a chassis or, at the very least, re-patching some cables. Now, the scenario has changed, and the complex infrastructures built to cater for multi-tenant environments such as cloud hosting, or microservice-based deployments, require a network that is more agile and flexible. This has led to the emergence of Software-Defined Networking (SDN), an approach that centralizes the network configuration (where historically it was configured on a per-device basis) and results in a network topology being defined as a whole, rather than as a series of component parts. It is, if you like, an abstraction layer for the network itself and thus implies that just like infrastructure as a service, networks can now be defined in code.

Since the previous edition...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do – for those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 LTS, unless stated otherwise, and on Ansible 4.3. The example code that accompanies this chapter can be downloaded from GitHub at this URL: https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter13.

Check out the following video to see the Code in Action:https://bit.ly/3G5pNjJ.

Ansible for network management

Core network devices, such as switches, routers, and firewalls, have long had management interfaces, especially in enterprise environments. Command-Line Interfaces (CLIs) have always been popular on such devices as they support scripting, so, as you have already guessed, they lend themselves extremely well to Ansible automation.

Historically, teams have faced a myriad of challenges when managing these devices, including maintaining configuration, coping with the failure/loss of a device, and obtaining support in the event of an issue. Often, companies found themselves locked into a single network vendor (or at best, a small handful) to enable the use of proprietary tools to manage the network. As with any situation where you are locked into a technology, this carries both benefits and drawbacks. Add to this the complexity of software-defined networks that are rapidly changing and evolving, and the challenge becomes even greater. In this section, we...

Handling multiple device types

In a world where we are not locked into a single vendor, it is important to know how we might handle the different network devices in an infrastructure. We established in the previous chapter that for different infrastructure providers, a similar process was established for each one in terms of getting Ansible to interact with it. This can be a little different with switches as not all command-line switch interfaces are created the same. Some, such as on a Cumulus Networks switch, can make use of straightforward SSH connectivity, meaning that everything we have learned about in this book so far on connecting to an SSH-capable device still applies.

However, other devices, such as F5 BIG-IP, do not use such an interface and therefore require the module to be run from the Ansible host. The configuration parameters must be passed to the module directly as opposed to using simple connection-related host variables such as ansible_user. ...

Working with the cli_command module

Before we get to the practical hands-on examples, we must look at a module that has become central to network device configuration since the previous edition of this book was published.

As we discussed in the preceding section, most network devices cannot be expected to have a working Python environment on them, and as such, Ansible will use local execution – that is to say, all tasks related to network devices are executed on the Ansible control node itself, translated into the correct format for the device to receive (be that a CLI, an HTTP-based API, or otherwise), and then sent over the network to the device. Ansible 2.7 relied mostly on a communication protocol known as local for network device automation. This worked well but suffered from several drawbacks, including the following:

• The local protocol does not support persistent network connections – a new connection needs to be set up and then torn down for each task...

Configuring Arista EOS switches with Ansible

Getting up and running with an Arista switch (or virtual switch) is left as an exercise f or you, but if you are interested in doing this in GNS3, a popular and freely available open source tool for learning about networks, there is some excellent guidance here: https://gns3.com/marketplace/appliances/arista-veos.

You might be lucky enough to have an Arista EOS-based device at your fingertips, and that's fine too – the automation code in this section will work equally well in either case.

The following examples were created against an Arista vEOS device in GNS3, created using the instructions found in the aforementioned link. Upon booting the device for the first time, you will need to cancel ZeroTouch provisioning. To do this, log in with the admin username (the password is blank by default) and enter the following command:

zerotouch cancel

The virtual device will reboot, and when it comes up again, log in using...

Configuring Cumulus Networks switches with Ansible

Cumulus Linux (created by Cumulus Networks, which was acquired by NVIDIA) is an open source network operating system that can run on a variety of bare metal switches, offering an open source approach to data center networking. This is a great leap forward for network design and a significant shift away from the proprietary models of the past. They offer a free version of their software that will run on the hypervisor of your choice for test and evaluation purposes called Cumulus VX. The examples in this section are based on Cumulus VX version 4.4.0.

Defining our inventory

A quick bit of research shows us that Cumulus VX will use the standard SSH transport method of Ansible. Since it is a Linux distribution designed specifically to run on switch hardware, it is capable of running in remote execution mode, so it does not require the ansible.netcommon.network_cli protocol. Furthermore, just one module has been defined...

Best practices

All the usual best practices of using Ansible apply when automating network devices with it. For example, never store passwords in the clear, and make use of ansible-vault where appropriate. Despite this, network devices are their own special class of devices when it comes to Ansible, and support for them started to flourish from the 2.5 release of Ansible onward. As such, there are a few special best practices that deserve to be mentioned when it comes to network automation with Ansible.

Inventory

Make good use of the inventory structure supported by Ansible when it comes to organizing your network infrastructure and pay particular attention to grouping. Doing so will make your playbook development much easier. For example, suppose you have two switches on your network – one is a Cumulus Linux Switch, as we examined previously, and the other is an Arista EOS-based device. Your inventory may look like this:

[switches:children...

Summary

As more and more of our infrastructure gets defined and managed by code, it becomes ever more important that the network layer can be automated effectively by Ansible. A great deal of work has gone into Ansible since the previous release of this book in precisely this area, especially since the release of Ansible 2.5. With these advancements, it is now easy to build playbooks to automate network tasks, from simple device changes to rolling out entire network architectures through Ansible. All of the benefits of Ansible relating to code reuse, portability, and so on are available to those who manage network devices.

In this chapter, you learned about how Ansible enables network management. You learned about effective strategies for handling different device types within your infrastructure and how to write playbooks for them, and then you expanded on this with some specific examples on Arista EOS and Cumulus Linux. Finally, you learned about some of the best practices that...

Questions

Answer the following questions to test your knowledge of this chapter:

1. Ansible brings all the benefits of automation from infrastructure management to the world of network device management.

   a) True

   b) False

2. When working with a new network device type for the first time, you should always do what?

   a) Perform a factory reset of the device.

   b) Consult the Ansible documentation to learn about which collections and modules support it, and what the requirements for those might be.

   c) Use the ansible.netcommon.network_cli connection protocol.

   d) Use the local connection protocol.

3. Which execution type is described by Ansible as running its automation code on the remote host directly?

   a) Remote execution

   b) Local execution

4. Which execution type is described by Ansible as running its automation code on the control node, and then sending the required data over a pre-selected channel (for example, SSH or an HTTP-based API)?

   a) Remote execution

   b) Local execution

5. Which connection...

Why subscribe?

• Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
• Improve your learning with Skill Plans built especially for you
• Get a free eBook or video every month
• Fully searchable for easy access to vital information
• Copy and paste, print, and bookmark content

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [e-mail] for more details.

At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.