Category: automation

Anne Baretta got pretty far in his automation story: after starting with configuration templates and storing network inventory into a database, he tackled the web UI. What’s next? How about a few auto-generated network diagrams?

Notes

• We covered the magic behind network diagrams in our network automation course.
• For whatever reason, I see numerous networking engineers focusing on generating useful network diagrams. Wasn’t that problem solved ages ago with miraculous single-pane-of-glass network management software?

Imagine you followed the steps taken by Anne Baretta and stored network inventory into a database. What could you do with that information (apart from creating reports)? How about adding a web UI to help less-skilled network operators perform automated tasks?

Notes

• While we won’t tell you how to build a web UI in our network automation course, we will tell you how to build a system out of numerous components (and what components you might need).

What’s the next logical automation step after you cleaned up device configurations and started using configuration templates? It obviously depends on your pain points; for Anne Baretta it was a network inventory database stored in SQL tables (and thus readily accessible from his other projects).

Notes

• I’m always amazed that we have to solve simple problems decades after the glitzy slide decks from network management vendors proclaimed them solved;
• I’m also saddened that it’s often really hard to get data out of a network management product;
• Check out our network automation course when you’re ready to start your own automation journey.

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 ;)