Category: automation

This is a guest blog post by Dave Crown, Lead Data Center Engineer at the State of Delaware. He can be found automating things when he's not in meetings or fighting technical debt.

In a recent blog post, Ivan postulated “You’d execute a REST API call. Any one of those calls might fail. Now what? ... You’ll have absolutely no help from the orchestration system because REST API is not transactional so there’s no rollback.” Well, that depends on the orchestration system in use.

The promise of controller-based solutions (ACI, NSX, etc.) is that your unicorn powered network controller should be an all seeing, all knowing platform managing your network. We all have hopefully learned about the importance of backups very early on our careers. Backup and, more importantly, restore should be table stakes; a fundamental feature of any network device, let alone a networking system managed by a controller imbued with magical powers (if the vendor is to be believed).

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

I was walking down the infinite hallways of Cisco Live Europe chatting with the fellow Tech Field Day Extra delegates when I probably blanked out for a minute as the weirdest of thoughts hit me: “REST API is not transactional”

TL&DR: Apart from using structured data and having error codes REST API is functionally equivalent to Cisco IOS CLI from 1995

This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.

We’d like to be able to automate our network deployment and management from a single source of truth, but before we get there from a running (enterprise, campus!) network, we’ll have to take some small steps first.

These posts are not focused on 802.1x, but it serves as a nice use case in which I’ll show you how automation can save time and bring some consistency and uniformity to the network (device) configuration.

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

One of my readers sent me this question:

Would you write about methods for reverting from expected new state to old state in the case automation went wrong due to (un)predictable events that left a node or network in a limbo state betwixt and between.

Like always, there’s the easy and the really hard part.

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.

Following the Ivan’s post about Firewall Ruleset Automation, I decided to take a step forward: can we always have up-to-date and clean firewall policies without stale rules?

The problem

We usually configure and manage firewalls using a process like this:

An attendee of our Building Network Automation Solutions online course decided to automate his NSX-T environment and sent me this question:

I will be working on NSX-T quite a lot these days and I was wondering how could I automate my workflow (lab + production) to produce a certain consistency in my work.

I’ve seen that VMware relies a lot on PowerShell and I’ve haven’t invested a lot in that yet … and I would like to get more skills and become more proficient using Python right now.

Always select the most convenient tool for the job, and regardless of personal preferences PowerShell seems to be the one to use in this case.

Remember the previous blog post in this sequence in which I explained the need for single source-of-truth used in your network automation solution? No? Please read it first ;)

Ready for the next step? Assuming your sole source-of-truth is the actual device configuration, is there a magic mechanism we can use to transform it into something we could use in network automation?

TL&DR: No.

This is a guest blog post by Dave Crown, Lead Data Center Engineer at the State of Delaware. He can be found automating things when he's not in meetings or fighting technical debt.

Over the course of the last year or so, I’ve been working on building a solution to deploy and manage Cisco’s ACI using Ansible and Git, with Python to spackle in cracks. The goal I started with was to take the plain-text description of our network from a Git server, pull in any requirements, and use the solution to configure the fabric, and lastly, update our IPAM, Netbox. All this without using the GUI or CLI to make changes. Most importantly, I want to run it with a simple invocation so that others can run it and it could be moved into Ansible Tower when ready.

The first time I encountered screen scraping was in mid-1990. All business applications were running on IBM mainframes those days, and IBM used proprietary terminal system (remember 3270) that was almost impossible to interact with, so some people got the “bright” idea of emulating that screen, scraping information off the emulated screen and copying it into HTML pages… thus webifying their ancient apps.

Guess what – we’re still doing the very same thing in network automation as Andrea Dainese succinctly explained in the latest addition to his Automation for Cisco NetDevOps article.

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

Here’s a question I got from one of the attendees of my network automation online course:

We had a situation where HSRP was configured on two devices and then a second change was made to use a different group ID. The HRSP mac address got "corrupted" into one of devices and according to the vendor FIB was in an inconsistent state. I know this may be vendor specific but was wondering if there is any toolkit available with validation procedures to check if FIB is consistent after implementing L3 changes.

The problem is so specific (after all, he’s fighting a specific bug) that I wouldn’t expect to find a generic tool out there that would solve it.

Wherever you look you find three kinds of people: those that build tools they need, those that find the tools they need, and those that yammer about the lack of tools without ever doing anything to solve the problem.

Daniel Teycheney is clearly in the first category. When faced with “collect some data and create a simple report” hands-on assignment during the Building Network Automation Solutions course he started creating a toolbox of playbooks that can be used in initial network auditing. I’m positive you’ll find tons of useful tidbits in his code ;)

Want to be able to do something similar? You missed the Spring 2019 online course, but you can get the mentored self-paced version with Expert Subscription.

In the first blog post of this series I described how you could start building the prerequisite for any network automation solution: the device inventory.

Having done that, you should know what is in your network, but you still don’t know how your network is supposed to work and what services it is supposed to provide. Welcome to the morass known as building your source-of-truth.

A month ago Josef Fuchs described the process he uses to merge existing Cisco IOS device configuration with configuration snippets generated by his network automation solution.

In the second part of his article he dived deep into implementation details, described Ansible playbook and Jinja2 templates he’s using, how he optimized the solution with a custom Jinja2 filter, and the caveats he encountered.

A long while ago I published my solution for automated L3VPN provisioning… and I’m really glad I can point you to a much better one ;)

Håkon Rørvik Aune decided to tackle the same challenge as his hands-on assignment in the Building Network Automation Solutions course and created a nicely-structured and well-documented solution (after creating a playbook that creates network diagrams from OSPF neighbor information).

Want to be able to do something similar? You missed the Spring 2019 online course, but you can get the mentored self-paced version with Expert Subscription.

This is one of the “thinking out loud” blog posts as I’m preparing my presentation for the Building Network Automation Solutions online course. I’m probably missing a gazillion details - your feedback would be highly appreciated

One of the toughest challenges you’ll face when building a network automation solution is “where is my source of truth” (or: what data should I trust). As someone way smarter than me said once: “You could either have a single source of truth of many sources of lies”, and knowing how your devices should be configured and what mistakes have to be fixed becomes crucial as soon as you move from gathering data and creating reports to provisioning new devices or services.