For the first two sessions of the Building Network Automation Solutions online course I got awesome guest speakers, and it seems we’ll have another fantastic lineup in the Spring 2018 course:

Most network automation solutions focus on device configuration based on user request – service creation or change of data model describing the network. Another very important but often ignored aspect is automatic response to external events, and that’s what David Gee will describe in his presentation.

Here’s a quote from one of my friends who spent years working with Ansible playbooks:

Debugging Ansible is one of the most terrible experiences one can endure…

It’s not THAT bad, particularly if you have a good debugging toolbox. I described mine in the Debugging Ansible Playbooks part of the Ansible for Networking Engineers online course.

Please note that the Building Network Automation Solutions online course includes all material from the Ansible online course.

This blog post by Ethan Bank totally describes my (bad) Inbox habits. If you're anything like me, you might find Ethan's ideas useful (I do... following them is a different story, though).

A while ago (in the time of big-versus-small buffers brouhaha), I asked JR Rivers to do a short presentation focusing on buffering requirements of data center switches. He started by describing typical buffer architectures you might find in data center switches.

I got numerous responses to the “Why Does It Take So Long to Upgrade Network Devices,” the best ones coming from Béla Várkonyi and Frederic Cuiller.

Béla is sick-and-tired of the stuff vendors are shipping:

Every time we finish the Building Network Automation Solutions online course I ask the attendees to share their success stories with me. Stan Strijakov was quick to reply:

I have yet to complete the rest of the course and assignments, but the whole package was a tremendous help for me to get our Ansible running. We now deploy whole WAN sites within an hour.

Of course I wanted to know more and he sent me a detailed description of what they’re doing:

Here’s a question I got on one of my ancient blog posts:

How many OSPF process ID can be used in a single VRF instance?

Seriously? You have to ask that? OK, maybe the question isn’t as simple as it looks. It could be understood as:

When I started my ipSpace.net project life was simple: I had a few webinars, and you could register for the live sessions. After a while I started adding recordings, subscriptions, bundles, roadmaps (and tracks), books… and a few years later workshops and online courses.

As you can imagine, the whole thing became a hard-to-navigate mess. Right now you can buy almost 70 different products on ipSpace.net. Time for a cleanup.

Diptanshu Singh wrote a nice explanation of the math behind reliability calculations. Definitely worth reading even if you hated statistics.

Dave Taht sent me a link to IRTT after I published a blog post on measuring end-to-end latency with an Ansible playbook. Definitely looks like a tool worth having in your toolbox.