Category: automation

One of my readers was so delighted that something finally happened after I wrote about a NX-OS bug that he sent me a pointer to another one that has been pending for a long while, and is now officially terminated as FAD (Functions-as-Designed… even documented in the Further Problem Description).

Here’s what he wrote (slightly reworded)…

Netfortius made an interesting comment to my Ansible playbook as a bash script blog post:

Ivan - aren't we now moving the "CLI"[-like] approach, upstream (the one we are just trying to depart, via the more structured and robust approach of RESTAPI).

As I explained several times, I don’t know where the we must get rid of CLI ideas are coming from; the CLI is root of all evil mantra is just hype generated by startups selling alternative approaches (the best part: one of them was actually demonstrating their product using CLI).

Whitespace handling is one of the most confusing aspects of Jinja2, thoroughly frustrating many attendees of my Ansible and Network Automation online courses.

I decided to fix that, ran a few well-controlled experiments, and documented the findings and common caveats in Whitespace Handling in Jinja2 video.

After explaining the basics of PowerShell, Mitja Robas described how to do implement the “Hello, World!” of network automation (collecting printouts from network devices) in PowerShell.

To watch all videos from this free webinar, register here.

You’ll need at least free ipSpace.net subscription to watch the video.

Got this feedback on my Ansible for Networking Engineers webinar:

This webinar is very comprehensive compared to any other Ansible webinars available out there. Ivan does great job of mapping and using real life example which is directly related to daily tasks.

The Ansible online course is even better: it includes support, additional hands-on exercises, sample playbooks, case studies, and lab instructions.

However, Ansible is just a tool that shouldn’t be missing from your toolbox. If you need a bigger picture, consider the Building Network Automation Solutions online course (and register ASAP to save $700 with the Enthusiast ticket).

One of my readers sent me a question about his favorite annoyance:

During my long practice, I’ve never seen an Enterprise successfully managing the network device software upgrade/patching cycles. It seems like nothing changed in the last 20 years - despite technical progress, in still takes years (not months) to refresh software in your network.

There are two aspects to this:

I know that everyone learns in a slightly different way. Let me share the approach that usually works well for me when a tough topic I’m trying to master includes a practical (hands-on) component: running controlled experiments.

Sounds arcane and purely academic? How about a simple example?

A week ago I talked about this same concept in the Building Network Automation Solutions online course. The video is already online and you get immediate access to it (and the rest of the course) when you register for the next live session.

We’re slowly wrapping up the autumn 2017 Building Network Automation Solutions online course, so it’s time to schedule the next one. It will start on February 13th and you can already register (and save $700 over regular price as long as there are Enthusiast tickets left).

Do note that you get access to all course content (including the recordings of autumn 2017 sessions) the moment you register for the course. You can also start building your lab and working on hands-on exercises way before the course starts.

After explaining the challenges of data center fabric deployments, Dinesh Dutt focused on a very important topic I covered in Week#3 of the Building Network Automation Solutions online course: how do you separate data (data model describing data center fabric) from code (Ansible playbooks and device configurations)

It’s always great to see students enrolled in Building Network Automation Solutions online course using ideas from my sample playbooks to implement a wonderful solution that solves a real-life problem.

James McCutcheon did exactly that: he took my LLDP-to-Graph playbook and used it to graph VLANs stretching across multiple switches (and provided a good description of his solution).

One of my readers coming from system development area asked a fundamental question about the role of automation in enterprise IT (somewhat paraphrased):

[In system development] we automate typical tasks from the pre-defined task repository, so I would like to understand broader context as the automation (I guess) is just a part of the change we want to do in the system. Someone needs to decide what to do, someone needs to accept the change and finally the automation is used.

Of course he’s absolutely right.

One of the undergraduate students attending my Ansible for Networking Engineers online course got to the point where he wanted to start hands-on work and sent me a list of questions:

Do I have to buy a VIRL license to use your Ansible course materials? Or is VIRL in any Github repository? Is there a way to use your files in a free Tool like GNS3?

Let’s go through them one by one:

One of the sample Ansible playbooks I published to help the attendees of my Building Network Automation Solutions course get started collects LLDP neighbor information on all managed devices and converts that information into a network diagram.

Here’s the graph I got from it when I ran it on my 6-node OSPF network (the Inter-AS VIRL topology from this repository). Please note I spent zero time tweaking the graph description (it shows).

Got this comment on one of my blog posts:

When looking at some of the CLIs just front-ending RESTAPIs, I wonder if "survival" of CLI isn't just in the eyes of the beholder.

It made me really sad because I wrote about this exact topic several times… obviously in vain. Or as one of my network automation friends said when I asked him to look at the draft of this blog post:

Validating the expected network behavior is (according to the intent-driven pundits) a fundamental difference that makes intent-driven products more than glorified orchestration systems.

Guess what: smart people knew that for ages and validated their deployments even when using simple tools like Ansible playbooks.

Dinesh Dutt explained how he validates data center fabric deployment during the Network Automation Use Cases webinar; I’m doing something similar in my OSPF deployment playbooks (described in detail in Ansible online course).