A journey of a thousand miles begins with one step they say… but what should that first step be if you want to start a network automation journey (and have no idea how to do it)?

Anne Baretta sent me a detailed description of his journey, which (as is often the case) started with the standardized configuration templates.

If your automation solution relies on a back-end database with strict database schema you can stop reading… but if you (like most others) still live in the land of text files encoded in your favorite presentation format (because it’s hip to hate YAML), you might appreciate the solution Donald Johnson uses to check his data models before committing them into Git repository.

I always tell networking engineers attending our Building Network Automation Solutions online course to create minimalistic data models with (preferably) no redundant information. Not surprisingly, that’s a really hard task (see this article for an example) - using a simple automation tool like Ansible you end with either a messy and redundant data model or Jinja2 templates (or Ansible playbooks) full of hard-to-understand and impossible-to-maintain business logic.

Stephen Harding solved this problem the right way: his data center fabric deployment solution uses a dynamic inventory script that translates operator-friendly fabric description (data model) into template-friendly set of device variables.

Stumbled upon a 35-year-old article describing the ironies of automation (HT: The Morning Paper). Here’s a teaser…

Unfortunately automatic control can ‘camouflage’ system failure by controlling against the variable changes, so that trends do not become apparent until they are beyond control.

In simpler words: when things fail, they fail really badly because the intermittent failures were kept hidden. Keep that in mind the next time someone tells you how wonderful software-defined AI-assisted networking is going to be.

A month ago I described how Paddy Kelly used pyATS to get VRF data from a Cisco router to create per-VRF connectivity graphs.

Recently he also wrote a short article describing how to get started with pyATS and Ansible. Thank you, Paddy!

No, we were not talking about IP fabrics in general - IP Fabric is a network management software (oops, network assurance platform) Gian Paolo discovered a while ago and thoroughly tested in the meantime.

He was kind enough to share what he found in Episode 107 of Software Gone Wild, and as Chris Young succinctly summarized: “it’s really sad what we still get excited about something 30 years after it was first promised”… but maybe this time it really works ;)

Here’s another “let’s use network automation tools to create reports we couldn’t get in the past” (like IP multicast trees) solution coming from an attendee in our network automation course: Paddy Kelly created L3VPN graphs detailing PE-to-CE connectivity using Cisco’s pyATS to parse the Cisco IOS printouts.

You’ll find dozens of other interesting solutions on our Sample Network Automation Solutions page - all of them were created by networking engineers who knew almost nothing about network automation or open-source automation tools when they started our automation course.

Seth Godin published an interesting article on the value of hard work (and what hard work really is). Go and read it first, then we’ll translate it into networking terms.

Already back? Good, let’s go.

The first worker is a traditional networking technician (it wouldn’t be fair to call him an engineer) – he’s busy configuring VLANs, ACLs, firewall rules… the whole day.

I got interesting feedback from one of my readers after publishing my REST API Is Not Transactional blog post:

One would think a transactional REST interface wouldn’t be too difficult to implement. Using HTTP1/1, it is possible to multiplex several REST calls into one connection to a specific server. The first call then is a request for start a transaction, returning a transaction ID, to be used in subsequent calls. Since we’re not primarily interested in the massive scalability of stateless REST calls, all the REST calls will be handled by the same frontend. Obviously the last call would be a commit.

I wouldn’t count on HTTP pipelining to keep all requests in one HTTP session (mixing too many layers in a stack never ends well) but we wouldn’t need it anyway the moment we’d have a transaction ID which would be identical to session ID (or session cookie) traditional web apps use.

TL&DR: You automate the whole process. What else do you expect?

During the Tech Field Day Extra @ Cisco Live Europe 2019 we were taken on a behind-the-stage tour that included a chat with people who built the Cisco Live network, and of course I had to ask how they automated the whole thing. They said “well, we have the guy that wrote the whole system onsite and he’ll be able to tell you more”. Turns out the guy was my good friend Andrew Yourtchenko who graciously showed the system they built and explained the behind-the-scenes details.

How nice would it be to have a fabric health dashboard displaying a summary of numerous parameters you’re interested in (number of operational uplinks, number of BGP sessions…) for every switch in your fabric.

I’m positive you could hack something together using the customization capabilities of your favorite network management system… or you could write a simple data gathering solution like Stephen Harding did while attending the Building Network Automation Solutions online course.

Have you ever seen an Ansible playbook where 90% of the code prepares the environment, and then all the work is done in a few template and assemble modules? Here’s an alternative way of getting that done. Is it better? You tell me ;)

Remember Nicky Davey describing how he got large DMVPN deployment back on track with configuration templating? In his own words…:

Configuration templating is still as big win a win for us as it was a year ago. We have since expanded the automation solution, and reading the old blog post makes me realise how far we have come. I began working with this particular customer in May 2017, so 2 years now. At that time the new WAN project was on the horizon and the approach to network configuration was entirely manual.

Here’s how far he got in the meantime:

Last week I covered network security groups, application security groups and user-defined routes in the second live session of Azure Networking webinar.

We also had a great guest speaker on the Network Automation course: Damien Garros explained how he used central source-of-truth based on NetBox and Git to set up a network automation stack from the grounds up.

Recordings are already online; you’ll need Standard ipSpace.net Subscription to access the Azure Networking webinar, and Expert ipSpace.net Subscription to access Damien’s presentation. Azure Networking webinar is also part of our new Networking in Public Clouds online course.

A while ago Ruben Tripiana tried to configure BGP on Cisco IOS using IETF YANG data models… and failed. In Spring 2019 Building Network Automation Solutions online course Chris Crook decided to deploy BGP routing on multiple platforms using YANG data models instead of configuration templates. Not only did he succeed, he also documented his work and the tools he used, and published the solution so you can replicate his efforts.

You can find many more network automation solutions created by the attendees of our automation course in solutions showcase.