If you’ve been in networking long enough you’d probably noticed an interesting pattern:

• Some topic is hotly debated;
• No agreement is ever reached even though the issue is an important one;
• The debate dies after participants diverge enough to stop caring about the other group.

I was reminded of this pattern when I was explaining the traffic filtering measures available in private and public clouds during the Designing Infrastructure for Private Clouds workshop.

Chris Crook decided to work on a pretty typical problem for his second hands-on assignment in the Building Network Automation Solutions online course: create a network diagram from adjacency data.

He decided to rely on BGP adjacencies (I would usually use LLDP) and added an interesting twist: instead of Ansible he used Nornir with NAPALM.

If you’re a BGP newbie, you’ll love this BGP Show and Tell series from Denise Fishburne. Enjoy!

I mentioned Multipath TCP (MP-TCP) numerous times in the past but I never managed to get beyond “this is the thing that might solve some TCP multihoming challenges” We fixed this omission in Episode 100 of Software Gone Wild with Christoph Paasch (software engineer @ Apple) and Mat Martineau from Open Source Technology Center @ Intel.

Remember the previous blog post in this sequence in which I explained the need for single source-of-truth used in your network automation solution? No? Please read it first ;)

Ready for the next step? Assuming your sole source-of-truth is the actual device configuration, is there a magic mechanism we can use to transform it into something we could use in network automation?

TL&DR: No.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

I made a statement along these lines in an SD-WAN blog post and related email sent to our SDN and Network Automation mailing list:

The architecture of most SD-WAN products is thus much cleaner and easier to configure than traditional hybrid networks. However, do keep in mind that most of them use proprietary protocols, resulting in a perfect lock-in.

While reading that one of my readers sent me a nice email with an interesting question:

This is a guest blog post by Dave Crown, Lead Data Center Engineer at the State of Delaware. He can be found automating things when he's not in meetings or fighting technical debt.

Over the course of the last year or so, I’ve been working on building a solution to deploy and manage Cisco’s ACI using Ansible and Git, with Python to spackle in cracks. The goal I started with was to take the plain-text description of our network from a Git server, pull in any requirements, and use the solution to configure the fabric, and lastly, update our IPAM, Netbox. All this without using the GUI or CLI to make changes. Most importantly, I want to run it with a simple invocation so that others can run it and it could be moved into Ansible Tower when ready.

TL&DR: We ran two workshops in Zurich last week – a quick peek into using Ansible for network automation and updated Building Private Cloud Infrastructure. You can access workshop materials with any paid ipSpace.net subscription.

Now for the fun part…

I got great feedback about the first part of Data Center Interconnects webinar from one of ipSpace.net subscribers:

I had no specific expectation when I started watching the material and I must have watched it 6 times by now.

Your webinar covered just the right level of detail to educate myself or refresh my knowledge on the technologies and relevant options for today’s market choices

The information provided is powerful and avoids useless discussions which vendors and PowerPoint pitches. Once you ask the right question it’s easy to get an idea of the vendor readiness

In the first live session we covered the easy cases: design considerations, and layer-3 interconnect with path separation (multiple routing domains). The real fun will start in the second live session on March 19^th when we’ll dive into stretched VLANs and long-distance vMotion ideas.

You can attend the live session with any paid ipSpace.net subscription – details here.

The first time I encountered screen scraping was in mid-1990. All business applications were running on IBM mainframes those days, and IBM used proprietary terminal system (remember 3270) that was almost impossible to interact with, so some people got the “bright” idea of emulating that screen, scraping information off the emulated screen and copying it into HTML pages… thus webifying their ancient apps.

Guess what – we’re still doing the very same thing in network automation as Andrea Dainese succinctly explained in the latest addition to his Automation for Cisco NetDevOps article.