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

One of the common questions we get in the Building Network Automation Solutions online course is “how do I create device inventory if I don’t know (exactly) what devices are in my network?”… prompting one of the guest speakers to reply “could it really be that bad?” (yes, sometimes it is).

Some of the students tried to solve the challenge with Ansible. While that might eventually work (given enough effort), Ansible definitely isn’t the right tool for the job.

What you need to get the job done is a proper toolchain:

Ladies and gentlemen, our Autumn 2019 Building Network Automation Solutions online course is now ready for boarding. Please make sure you have your boarding passes ready, board at your convenience, and start enjoying the pre-flight perks like over hundred hours of self-study materials.

Our flight will depart on September 3^rd with subsequent sessions on September 26^th, October 24^th and November 12^th. The guest speakers will focus on security, inventory managements, and describe their production deployments. More in a few days…

Tom Limoncelly wrote another must-read ACM Queue article: Top Ten Things Executives Should Know About Software. If only someone as eloquent as Tom would write a networking equivalent...

Topology changes are a bane of large STP-based networks, and when they become a serious challenge you could probably use a tool that could track down what’s causing them.

I’m sure there’s a network management tool out there that can do just that (please write a comment if you know one); Eder Gernot decided to write his own while working on a hands-on assignment in the Building Network Automation Solutions online course. Like most course attendees he published the code on GitHub and might appreciate pull requests ;)

One of my readers sent me this email after reading my Loop Avoidance in VXLAN Networks blog post:

Not much has changed really! It’s still a flood/learn bridged network, at least in parts. We count 2019 and talk a lot about “fabrics” but have 1980’s networks still.

The networking fundamentals haven’t changed in the last 40 years. We still use IP (sometimes with larger addresses and augmentations that make it harder to use and more vulnerable), stream-based transport protocol on top of that, leak addresses up and down the protocol stack, and rely on technology that was designed to run on 500 meters of thick yellow cable.

My first Cisco router was a blade for a Cabletron modular hub (anyone remembers what hubs were or a company named Cabletron?). We plugged it in, I read the documentation, figured out I had to type conf t and was faced with a blinking cursor staring back at me from an empty line.

A few years later I was invited to beta test Cisco software release 9.21 (it wasn’t called IOS yet). The best feature it had was the awesome configuration CLI with context-sensitive prompts and on-demand help.

Have you ever wondered how many free ports you have on your stackable campus switches? I’m sure there must be a wonderful network management tool that creates that reports with a click of a button… but what if the tool your PHB purchased based on awesome PowerPoint and glitzy demo can’t do that?

Nadeem Lughmani decided to solve this challenge as a hands-on assignment in the Building Network Automation Solutions online course and created an Ansible playbook and a Python plugin that counts the total number of ports and number of free ports for each switch stack specified in the device inventory.

We all know about catastrophic headline-generating failures like AWS East-1 region falling apart or a major provider being down for a day or two. Then there are failures known only to those who care, like losing a major exchange point. However, I’m becoming more and more certain that the known failures are not even the tip of the iceberg – they seem to be the climber at the iceberg summit.

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

One of the common questions I get once the networking engineers progress from Ansible 101 to large-scale deployments (example: generating configurations for 1000 devices) is “Can Ansible use a relational database? Text files don’t scale…”

TL&DR answer: Not directly, but there are tons of database Ansible plugins or custom Jinja2 filters out there.

Remember how Nick Buraglio tried to use OpenDaylight to build a small part of SuperComputing conference network… and ended up with a programmable patch panel?

This time he repeated the experiment using Faucet SDN Controller – an OpenFlow controller focused on getting the job done – and described his experience in Episode 101 of Software Gone Wild.

We started with the usual “what problem were you trying to solve” and quickly started teasing apart the architecture and got geekily focused on interesting things like: