Category: automation

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

David Gee (whom I finally met in person during recent ipSpace.net Summit) published a fantastic series of articles on what someone bringing together networking, development and automation should know and do.

In every SDDC workshop I tried to persuade the audience that the virtual appliances (particularly per-application instances of virtual appliances) are the way to go. I usually got the questions along the lines of “who will manage and audit all these instances?” but once someone asked “and how will we upgrade them?”

Short answer: you won’t.

In one of the previous blog posts I described the playbook I use to collect SSH keys from network devices. As I use it quite often, it became tedious to write ansible-playbook path-to-playbook every time I wanted to run the collection process.

Ansible playbooks are YAML documents, and YAML documents use # to start comments, so I thought “what if I’d use a YAML comment to add shebang and turn my YAML document into a script”

TL&DR: It works. Now for the longer story…

With all the intent-based hype (and the previous SDN-will-rule-the-world-hype) you’d think that the network is the ultimate ossified roadblock on the path to agile nirvana.

You’d be totally wrong (and you’d deserve it – never trust a vendor peddling a product).

Here’s an amazing discovery I made when I was still running on-site SDN and network automation workshops.

Here’s a common scenario I’m encountering on Ansible-related forums:

Q: I cannot connect to network devices with my Ansible network modules. I keep getting these weird error messages…

Me: Are you sure you have the device SSH keys in known_hosts file?

Q: How did you know?

A while ago I got a kind email from Kireeti Kompella, CTO @ Juniper Networks, saying “A colleague sent me an email of yours regarding SDN, the trough of disillusionment, and the rise of automation. Here's a more dramatic view: the Self-Driving Network -- one whose operation is totally automated.”

Even though Software Gone Wild podcast focuses on practical ideas that you could deploy relatively soon in your network, we decided to make an exception and talk about (as one of my friends described it) a unicorn driving a flying DeLorean with a flux capacitor.

If you’re a long-time reader of my blog you probably know that I believe in learning the fundamentals before trying to do anything else (like Google-and-Paste spaghetti wall approach), so you could imagine my delight when I got this feedback from an engineer watching (free) Network Programmability 101 webinar:

I was expecting a technical webinar, so I was a little bit disappointed at first with a “meta” webinar, but as I got through I was more than happy; learning such a meta sphere or getting to know other mindsets is very useful for me. The webinar pushed me to think outside of my little world and to open my mind.

That's exactly what I'm trying to achieve with the high-level webinars. So glad to hear it worked ;))

Long story short: I’m offering a few free seats in my Ansible for Networking Engineers online course to undergraduate or master’s students.

Interested? Check out the details, and apply before October 1^st.

Too old? Please spread the word ;)

PowerShell is a great scripting environment if your vendor provided PowerShell libraries to control their software or devices… but what if all you got is REST API (example: Nexus switches)?

We’ll conveniently ignore the challenges of managing devices that use 30-year-old non-scriptable CLI.