Category: automation

Matt Oswalt made two great points while tweeting about my Automation Gone Wild blog post:

• Automation should be a strategy. You need management buy-in;
• You should have at least one person with strong software development experience in your automation team.

However, life is not always rosy, so @stupidengineer asked:

Marcel Reuter sent me a few questions about my upcoming Network Automation workshop. You might find them interesting, so here they are:

We have a lab with virtual IOS-XE, IOS-XR and Junos (vMX) router. I would like to learn how to provisioning the Lab router.

Covered in the workshop. I’m focusing on vIOS (which is pretty close to IOS Classic and IOS-XE) and Nexus OS because that’s what I can get up and running quickly in VIRL.

My “this is why you need automation” blog post triggered numerous comments and tweets. I loved this one:

What if the mistake was embedded into the automation process/tool (designed by humans) in the first place? Now you have a video series titled "Automation Gone Wild".

I guess this tweet is a priceless answer to that question:

I spent the last week creating numerous scenarios using Ansible networking modules for my upcoming Network Automation workshop. The scenarios use Cisco IOS and Nexus OS modules as I used VIRL for network simulation, but you could easily adapt them to other networking devices.

All the scenarios I’m covering in the workshop are available in my Github repository; to get the them explained you’ll have to attend the workshop. Enjoy!

I stumbled upon a great description of how you can go bankrupt in 45 minutes due to a manual deployment process. The most relevant part of it:

Any time your deployment process relies on humans reading and following instructions you are exposing yourself to risk. Humans make mistakes. The mistakes could be in the instructions, in the interpretation of the instructions, or in the execution of the instructions.

And no, it's not just application deployment. A similar disaster could happen in your network.

Every time I have a network automation presentation (be it a 2-day workshop or a 45 minute keynote) I get the same question afterwards: “How do we deal with exceptions?”

The correct answer is obvious: “there should be no exceptions, because one-offs usually cost you more than you earn with them,” but as always the reality tends to intervene.

When I heard people talking about “networking infrastructure as code” I dismissed that as yet another Software-Defined-Everything one-controller-to-rule-it-all hype. Boy was I wrong.

To complete the exercises included in the Building Network Automation Solutions online course (or to do your own exploration into the world of network automation) you’ll need a reliable lab environment. There are three major steps you have to complete to get there:

• Create an environment capable of running network automation tools you want to use. We’ll focus on getting Ansible and NAPALM up and running.
• Build a networking lab using either physical or virtual devices.
• Establish connectivity between your network automation environment and your networking lab.

The rest of this document describes some of the potential approaches to building a network automation lab. Don’t limit yourself to what’s described here – go out and experiment.

You might also be interested in these alternative approaches:

• Full-blown development environment created by Carl Buchmann
• Building a Docker network automation container

Don’t Create a Science Project

Some networking engineers severely overestimate their skills in adjacent areas. Building a virtual lab for the first time with Vagrant and VirtualBox while fighting bugs in vendor Vagrant boxes can be a daunting task. If you’re new to Linux and virtual labs please try to keep things as simple as possible. Here are a few ideas (in increasing order of complexity):

• Use my quick recipe to create your network automation environment and use physical network devices (if nothing else, configure your home router);
• Install a workstation virtualization product (VirtualBox or VMware Fusion/Workstation) and create Linux VM and network devices from ISO images using GUI. You can still use my recipe and installation scripts to set up the network automation environment.
• Instead of creating individual VMs for network devices, set up VIRL or GNS3 and enable outside access to network devices.