Category: automation

One of the points David Gee, a guest speaker in Spring 2019 Building Networking Automation Solutions online course, and Christoph Jaggi touched on in their interview was the security of network automation solutions (see also: automated workflows and hygiene of network automation).

What are the security risks for automation?

Security is an approach, not an afterthought.

David Gee decided to talk about hygiene of network automation in the Spring 2019 Building Network Automation Solutions online course, and (not surprisingly) Christoph Jaggi wanted to know more:

You highlight the hygiene of automation. What is it and why does it matter?

Hygiene is the important but boring bit of automation most beginners and amateurs pass by.

After a series of forward-looking podcast episodes we returned to real life and talked with Carl Buchmann about his network automation journey, from managing upgrades with Excel and using Excel as the configuration consistency tool to network-infrastructure-as-code concepts he described in a guest blog post in February 2018

David Gee is coming back to Building Network Automation Solutions online course – in early March 2019 he’ll talk about hygiene of network automation. Christoph Jaggi did an interview with him to learn more about the details of his talk, and they quickly diverted into an interesting area: automated workflows.

Automation is about automated workflows. What kind of workflows can be automated in IT and networking?

Workflows most often fall into categorizations of build, operations and remediation.

You know that time of year when snowflakes mean more than description of uniqueness of your networking infrastructure? Some people love to complain about that season and how the weather hinders them, others put on sturdy winter boots and down jackets, change tires on their car, and have tons of fun.

Network automation is no different. Sometimes you can persuade your peers that it makes sense to simplify and standardize the infrastructure to make it easier to abstract and automate (consider that an equivalent of going to a tropic island with shiny beaches and everlasting summer), other times you have to take out your winter boots and make the best out of what you got.

In spring 2018 I started collecting real-life automation wins reported by the attendees of my Building Network Automation Solutions online course. I presented them at Troopers, and as a set of network automation use cases that are available to all ipSpace.net subscribers, some of them even with free subscription.

Today let’s start with how did it start story.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

After publishing the Manual Work Is a Bug blog post, I got this feedback from Michele Chubirka explaining why automating changes in your network also increases network security:

The “everyone should be a programmer” crowd did a really good job of scaring network engineers (congratulations, just what we need!). Here’s a typical question I’m getting:

Do I need to be good in scripting to attend your automation course.

TL&DR: Absolutely not.

This blog post was initially sent to subscribers of my mailing list. Subscribe here.

In his Intent-Based Networking Taxonomy blog post Saša Ratković mentioned real-time change validation as one of the requirements for a true intent-based networking product.

Old-time networking engineers would instinctively say “sure, we need that” while most everyone else might be totally flabbergasted. After all, when you create a VM, the VM is there (or you’d get an error message), and when you write to a file and sync the file system the data is stored, right?

As is often the case, networking is different.

This blog post was initially sent to subscribers of my mailing list. Subscribe here.

Following on his previous work with Cisco ACI Dirk Feldhaus decided to create an Ansible playbook that would create and configure a new tenant and provision a vSRX firewall for the tenant when working on the Create Network Services hands-on exercise in the Building Network Automation Solutions online course.

Event-driven automation (changing network state and/or configuration based on events) is the holy grail of network automation. Imagine being able to change routing policies (or QoS settings, or security rules) based on changes in the network.

We were able to automate simple responses with on-box solutions like Embedded Event Manager (EEM) available on Cisco IOS for years; modern network automation tools allow you to build robust solutions that identify significant events from the noise generated by syslog messages, SNMP traps and recently streaming telemetry, and trigger centralized responses that can change the behavior of the whole network.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of my readers asked a very valid question when reading the Why Is Network Automation So Hard blog post:

Why was network automation 'invented' now? I have been working in the system development engineering for 13+ years and we have always used automation because we wanted to save time & effort for repeatable tasks.

He’s absolutely right. We had fully-automated ISP service in early 1990’s, and numerous service providers used network automation for decades.

Building the network automation lab environment seems to be one of the early showstoppers on everyone’s network automation journey. These resources might help you get started:

• I wrote an installation script that installs the myriad dependencies needed by Ansible and NAPALM in just the right order on a Ubuntu VM (step-by-step instructions for ipSpace.net subscribers).
• Carl Buchmann open-sourced a full-blown infrastructure-as-code development environment he uses for his automation projects.
• Jaap de Vos described how he creates a Docker image containing Ansible, NAPALM and Nornir.

Hint: after setting up your environment, you might want to enroll into the Spring 2019 network automation course ;)

This is the fourth blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. Previous posts: Network-Infrastructure-as-Code Is Nothing New, Adjusting System State and NETCONF versus REST API.

Dmitri Kalintsev sent me a nice description on how some popular Infrastructure-as-Code (IaC) tools solve the challenges I described in The CRUD Hell section of Infrastructure-as-Code, NETCONF and REST API blog post:

This is the third blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. You might want to start with Network-Infrastructure-as-Code Is Nothing New and Adjusting System State blog posts.

As I described in the previous blog post, the hardest problem any infrastructure-as-code (IaC) tool must solve is “how to adjust current system state to desired state described in state definition file(s)”… preferably without restarting or rebuilding the system.

There are two approaches to adjusting system state: