Category: Automation

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.