Category: automation

Network automation is scary when you start using it in a brownfield environment. After all, it’s pretty easy to propagate an error to all devices in your network. However, there’s one thing you can do that’s usually pretty harmless: collect data from network devices and create summary reports or graphs.

I collected several interesting solutions created by attendees of our Building Network Automation Solutions online course and described them in a short video.

Want to create something similar? No time to procrastinate – the registration for the Spring 2019 course ends tomorrow.

This is a guest blog post by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG) and  Route Reflector Labs. These days you’ll find him busy automating Cisco ACI deployments.

In this post we’ll focus on a simple question that arises in numerous chats I have with colleagues and customers: how should a network engineer operate Cisco ACI? A lot of them don’t use any sort of network automation and manage their Cisco ACI deployments using the Web Interface. Is that good or evil? As you’ll see we have a definite answer and it’s not “it depends”.

Numerous network automation deployments happen in brownfield installations: you’re trying to automate parts of existing network deployment and operations processes. If you’re lucky you start automating deployment of new devices… but what if you have to automate parts of existing device configurations?

I know many networking engineers who went into networking because they didn’t want to write code the rest of their lives. I also know a few awesome engineers who decided to keep coding while designing networks.

Andrea Dainese (author of UNetLab – the tool you might know as EVE-NG) is one of the latter and practiced network automation for years, dealing with all sorts of crappy device configuration and monitoring mechanisms, from screen- and web scraping to broken REST APIs.

He decided to write a series of articles describing individual mechanisms, starting with an overview and zero-touch provisioning.

In summer 2018 Juniper started talking about another forward-looking concept: Network Reliability Engineering. We wanted to find out whether that’s another unicorn driving DeLorean with flux capacitors or something more tangible, so we invited Matt Oswalt, the author of Network Reliability Engineer’s Manifesto to talk about it in Episode 97 of Software Gone Wild.

In the first part of his interview with Christoph Jaggi Kristian Larsson talked about the basics of CI testing. Now let’s see how you can use these concepts in network automation.

How does CI testing fit into an overall testing environment?

Traditionally, in particular in the networking industry, it's been rather common to have proof of concepts (POC) delivered by vendors for various networking technologies and then people have sat down and manually tested that the POC meets some set of requirements.

As I’m doing occasional consulting for large enterprises redesigning their data centers, I encounter a wide range of network automation readiness, from “we don’t need that” to “how could we automate as much as possible”.

Based on the pervasiveness of “we don’t need that” responses it looks like many enterprise network engineers still have to go through the five stages of automation grief.

In spring 2019 Building Network Automation Solutions course we’ll have Kristian Larsson diving into continuous integration and his virtual networking lab product (you might want to listen to the Software Gone Wild episode we did with him to get a taste of what he’ll be talking about). Christoph Jaggi did a short interview with him starting with the obvious question:

What is CI testing and how does it differ from other testing methods?

CI is short for Continuous Integration and refers to a way of developing software where changes written by individual developers are frequently (or "continuously") integrated together into a master branch/trunk, thus continuous integration.

One of my readers sent me a description of their automation system that manages firewall rulesets on Fortigate firewalls using NAPALM to manage device configurations.

In his own words:

We are now managing thousands of address objects, services and firewall policies using David Barroso’s FortiOS Napalm module. This works very well and with a few caveats (such as finding a way to enforce the ordering of firewall policies) we are able to manage all the configuration of our firewalls from a single Ansible playbook.

The did the right thing and implemented an abstracted data model using GitOps to manage it:

One of the attendees of my Building Network Automation Solutions online course sent me this suggestion:

Stick to JUST Ansible - no GitHub, Vagrant, Docker or even Python - all of which come with their own significant learning curves.

While I understand how overwhelming the full-blown network automation landscape is to someone who never touched programming, you have to make a hard choice when you decide to start the learning process: do you want to master a single tool, or understand a whole new technology area and be able to select the best tool for the job on as-needed basis.

Last week we published the first half of interview with Patrick Ogenstad, guest speaker in Spring 2019 Building Network Automation Solutions online course (register here). Here’s the second half.

ZTP is about provisioning. Can this include configuration as well?

You could argue that provisioning is a form of configuration and in that sense, provisioning can certainly include configuration. If your ZTP solution is good at configuration management is another question.

The final topic David Gee and Christoph Jaggi mentioned in their interview was big data and AI (see also: automated workflows, hygiene of network automation and network automation security):

Two other concurrent buzzwords are big data and artificial intelligence. Can they be helpful for automation?

Big Data can provide a rich pool of event-sourcing information and, as infrastructures get more complex, it’s essential that automation triggers are as accurate as possible.

Zero-touch provisioning is always one of the big topics in the Building Network Automation Solutions online course, so we decided to invite Patrick Ogenstad (the author of excellent ZTP tutorial) to be a guest speaker in Spring 2019 course (register here).

In the meantime, enjoy his interview with Christoph Jaggi.

Last week we published Matt Oswalt’s thoughts on using virtual labs in training and testing. In the second part of his interview with Christoph Jaggi he talked about building a virtual lab.

Matt will cover the same topic in way more details in his guest speaker presentation in Spring 2019 Building Network Automation Solutions online course. Register here.

One of the fundamentals I always emphasize in introductory parts of my network automation workshops and online courses is the fact that we’re about to develop software that will control the most-mission-critical part of IT infrastructure, and should therefore use software development methodologies like version control, testing…

However, there’s a “small” glitch. While it’s perfectly possible to test most software in some virtual environment you can spin up on-the-fly using Vagrant, Docker, Jenkins, Travis, or some other CI/CD tool, testing a network automation solution requires access to network devices.