Author Archives: Sean Cavanaugh
Author Archives: Sean Cavanaugh
The Ansible Networking Team is excited about the release of Ansible 2.5. Back in February, I wrote about new Networking Features in Ansible 2.5, and one of the biggest areas of feedback was around the network_cli connection plugin. For more background on this connection plugin, please refer to the previous blog post.
In this post, I convert existing networking playbooks that use
connection: local to use
connection: network_cli. Please note that the passwords are in plain text for demonstration purposes only. Refer to the following Ansible Networking documentation page recommendation for using Ansible Vault for secure password storage and usage.
To demonstrate, let’s use an existing GitHub repository with working playbooks using the legacy connection local method. NOTE: The connection local method will continue to be supported for quite some time, and has not been announced as deprecated yet. This repository has several examples using Ansible and NAPALM but we are highlighting the Ansible Playbooks in this post. The GitHub repository can be found here.
Networking platforms use their specific
*_config platform module for easy backups within Ansible. For this playbook we are running the Ansible Playbook Continue reading
Just like with Windows and Linux servers, networking devices can be exploited by vulnerabilities found in their operating systems. Many IT organizations do not have a comprehensive strategy for mitigating security vulnerabilities that span multiple teams (networking, servers, storage, etc.). Since the majority of network operations is still manual, the need to mitigate quickly and reliably across multiple platforms consisting of hundreds of network devices becomes extremely important.
In Cisco’s March 2018 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication, 22 vulnerabilities were detailed. While Red Hat does not report or keep track of individual networking vendors CVEs, Red Hat Ansible Engine can be used to quickly automate mitigation of CVEs based on instructions from networking vendors.
In this blog post we are going to walk through CVE-2018-0171 which is titled “Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability.” This CVE is labeled as critical by Cisco, with the following headline summary:
“...a vulnerability in the Smart Install feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to trigger a reload of an affected device, resulting in a Continue reading
The Ansible 2.5 open source project release includes the following Infoblox Network Identity Operating System (NIOS) enablement:
For network professionals, this means that existing networking Ansible Playbooks can utilize existing Infoblox infrastructure for IP Address Management (IPAM), using Infoblox for tracking inventory and more. For more information on Infoblox terminology, documentation and examples, refer to the Infoblox website
Let’s elaborate on each of these Ansible 2.5 additions. All of the following examples (and many more) are provided in the network automation community project, under the infoblox_ansible Github repo. The integrations for Ansible require that the control node (where Ansible is being executed from) have the infoblox-client installed. It can be found here and installed with pip issuing the pip install infoblox-client command.
There are five new modules included with Ansible 2.5. They can be currently found in the development branch of the documentation:
Here is an example playbook on configuring a IPv4 network using the Continue reading
The upcoming Ansible 2.5 open source project release has some really exciting improvements, and the following blog highlights just a few of the notable additions. In typical Ansible fashion, development of networking enhancements is done in the open with the help of the community. You can follow along by watching the networking GitHub project board, as well as the roadmap for Ansible 2.5 via the networking wiki page.
A few highlighted features include:
Let's dive into each of these topics and elaborate on what they mean for your Ansible Playbooks!
Prior to Ansible 2.5, using networking modules required the connection type to be set to local. A playbook executed the python module locally, and then connected to a networking platform to perform tasks. This was sufficient, but different than how most non-networking Ansible modules functioned. In general, most Ansible modules are executed on the remote host, compared to being executed locally on the Ansible control node. Although many networking platforms can execute Python code, the vast Continue reading
One of the major networking features in Red Hat Ansible Engine 2.4 was the addition of aggregate resources to the networking modules. The Ansible networking team recently talked about this at the Ask an Expert webinar in November.
Simply put, aggregate resources are a better way to iterate (or loop) without the need to execute each task one by one. That is, you can now “aggregate” a collection as a single task instead of a collection of discrete loops.
Loop Method (with_items:)
Aggregate Method (aggregate:)
Based on feedback from customers, partners and community members, this post provides more examples and more detail of this important new feature. The simplest way to showcase this is to compare the old way and the new way, and highlight the differences Continue reading
Network Automation is so hot right now! Joking aside, DevOps tools like Ansible, Puppet, Chef and Salt as well as proprietary tools like Apstra are becoming all the rage in computer networks everywhere. There are python courses, network automation classes and even automation focused events for the first time in the history of computer networks (or at least it feels like it).
For this blog post I want to focus on automating network troubleshooting, the forgotten stepchild of network automation tasks. I think most automation tools focus on provisioning (or first time configuring) because so many network engineers are new to network automation in general. While I think that is great (and I want to encourage everyone to automate!) I think there is so much more potential for network automation. I am introducing Sean’s third category of automation use-cases — OPS!
I want to combine Cumulus NetQ, a fabric validation system, with Ansible to:
Because I think looking at terminal windows is super boring (no Continue reading
With the release of Ansible 2.3 the Cumulus Linux NCLU module is now part of Ansible core. This means when you `apt-get install ansible`, you get the NCLU module pre-installed! This blog post will focus on using the NCLU module to backup and restore configs on Cumulus Linux. To read more about the NCLU module from its creator, Barry Peddycord, click here.
The consulting team uses Ansible very frequently when helping customers fully automate their data centers. A lot of our playbooks use the Ansible template module because it is very efficient and idempotent, and Cumulus Linux has been built with very robust reload capabilities for both networking and Quagga/FRR. This reload capability allows the box to perform a diff on either `etc/network/interfaces` or `etc/quagga/Quagga.conf` so when a flat-file is overridden with the template module, only the “diff” (or difference) is applied. This means if swp1-10 were already working and we added configuration for swp11-20, an ifreload will only add the additional config and be non-disruptive for swp1-10. This reload capability is imperative to data centers and our customers couldn’t live without it.
As more and more network engineers dive into network automation, the word idempotence keeps coming up. What is it? Why is it important? Why should we care? Idempotence is often described as the ability to perform the same task repeatedly and produce the same result. I want to demonstrate a super simple example of what this means.
If I am logged into a Linux box and want to add an IP address to the loopback address, I could use something simple like a sed command.
[email protected]:mgmt-vrf:~# sed -i '/loopback/ a address 220.127.116.11/32' /etc/network/interfaces
This produces exactly what I want!
iface lo inet loopback
I have appended the address 18.104.22.168/32 to the loopback interface stanza of the /etc/network/interfaces file. Now what happens if I run that same exact command again?
Running the command again produces the following output:
iface lo inet loopback
That is not what I wanted. I performed the same task but instead of just leaving the file alone, since the 1.1.1. Continue reading
Host network configurations for MultiChassis Link Aggregation (MLAG, also referred to as dual-attach or ‘high availability’) can vary from host OS to host OS, even amongst Linux distributions. The most recommended and robust method is to use Link Aggregation Control Protocol (LACP), which is supported on most host operating systems natively. Host bonds or bonding refers to a variety of bonding methods, but for the purpose of this article it will refer to LACP bonds. The terms etherchannel, link aggregation group (LAG), NIC teaming, port-channel and bond can be used interchangeably to refer to LACP depending on the vendor’s nomenclature. For the sake of simplicity, we will just call it bonds or bonding. This post will take your through the steps for host network configurations for MLAG across five different operating systems.
Why LACP? LACP is a IEEE standard that has been available since 2000 known as 802.3ad. This makes a highly interoperable standards approach to bonding that can work across many network vendors and host operating systems. LACP is superior to static configuration (also referred to bond-mode ON) because there is a control protocol keeping the bond active. This means failover is predictable and automatic. This is also Continue reading
Oftentimes, Cumulus Linux gets confused for an SDN (software-defined networking) solution. In conversations with potential customers, I’ve noticed that some of them find it difficult to distinguish between SDN, open networking and Cumulus Linux. When I talk to network engineers, I start by clarifying the SDN buzzword head on. The term gets overused, and is often defined by other confusing acronyms or marketing jargon. To complicate things further, SDN is often thought of as equivalent to OpenFlow, which is flawed in my opinion.
If I were to more accurately describe SDN based on my experiences in the networking industry, I would define it more broadly. Instead of defining SDN as a specific solution (such as OpenFlow), I define SDN as a highly automatable and programmable network infrastructure.
Back in October, 2015, I spoke at All Things Open in Raleigh, North Carolina, an event focused on open technology and open source software. I was very excited by this event because many attendees work in or manage data centers, which means they are very familiar with Linux but have little experience with the networking stack. Cumulus Networks is the first major networking company to contribute a true Linux networking operating system for data center switches, which is highly disruptive to the industry and drives a lot of fun conversations with open-minded individuals.
The talk I did for All Things Open last October titled “Using DevOps Tools for Modern Data Centers” focuses on the new concept of NetDevOps or DevOps for Network devices. Since the network operating system is Cumulus Linux, why not use open source off-the-shelf automation tools that are already being leveraged in the data center to act as a controller. These tools have an extremely large user base, are vendor neutral — that is, not proprietary — and can scale easily.
So what are the benefits of using open source tools? One of the most important benefits from a networking point of view is provisioning. Imagine you have 1000 Continue reading