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

One of my readers sent me an interesting DMVPN routing question. He has a design with a single DMVPN tunnel with two hubs (a primary and a backup hub), running BGP between hubs and spokes and IBGP session between hubs over a dedicated inter-hub link (he doesn’t want the hub-to-hub traffic to go over DMVPN).

Here's (approximately) what he's trying to do:

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.

I listened to Ethan Banks’ presentation on lessons learned running active-active data centers years ago at Interop, and liked it so much that I asked him to talk about the same topic during the Building Next-Generation Data Center course.

Not surprisingly, Ethan did a stellar job, and when I heard he was working on QoS part of an upcoming book asked him whether he’d be willing to do a webinar on QoS.

Some of the things Ethan Banks writes are epic. The latest one I stumbled upon: Things Network Engineers Hate. I particularly loved the rant against long-distance vMotion (no surprise there ;).

One of the design scenarios we covered in Leaf-and-Spine Fabric Architectures webinar is a pure layer-3 data center, and in the “how do I do this” part of that section Dinesh Dutt talked about the details you need to know to get this idea implemented on Cumulus Linux.

We covered a half-dozen design scenarios in that webinar; for an even wider picture check out the new Designing and Building Data Center Fabrics online course.

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…

Second vendor in this year’s series of data center switching updates: Brocade.

Not much has happened on this front since last year’s update. There was a maintenance release of Brocade NOS, they launched SLX series of switches, but those are so new that the software documentation didn’t have time to make it to the usual place (document library for individual switch models), it's here.

In any case, the updated videos (including edited 2016 content which describes IP Fabric in great details) are online. You can access them if you bought the webinar recording in the past or if you have an active ipSpace.net subscription.

In case you’re not familiar with RFC 1925, Rule 5 states:

It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases, this is a bad idea.

Most routing protocols are a perfect demonstration of this rule.