Ansible network modules (at least in the way they’re implemented in Ansible releases 2.1 and 2.2) were one of the more confusing aspects of my Building Network Automation Solutions online course (and based on what I’m seeing on various chat sites we weren’t the only ones).

I wrote an in-depth explanation of how you’re supposed to be using them a while ago and now updated it with user authentication information.

One of the engineers watching my Data Center 3.0 webinar asked me why we need session stickiness in load balancing, what its impact is on load balancer performance, and whether we could get rid of it. Here’s the whole story from the networking perspective.

Remember the All You Need Are Two Switches saga? Several readers told me they’d like to have in text (article) format, so I found a transcription service, and started editing what they produced and publishing it. The first two installments are already online.

On a related topic: we’ll discuss the viability of this approach in April DIGS event in Zurich, Switzerland.

One of my readers watched my Leaf-and-Spine Fabric Architectures webinar and had a follow-up question:

You mentioned 3-tier architecture was dictated primarily by port count and throughput limits. I can understand that port density was a problem, but can you elaborate why the throughput is also a limitation? Do you mean that core switch like 6500 also not suitable to build a 2-tier network in term of throughput?

As always, the short answer is it depends, in this case on your access port count and bandwidth requirements.

In autumn 2016 I embarked on a quest to figure out how TCP really works and whether big buffers in data center switches make sense. One of the obvious stops on this journey was a chat with Thomas Graf, Linux Core Team member and a founding member of the Cilium project.

When Cisco ACI was launched it promised to do everything you need (plus much more, and in multi-hypervisor environment). It was quickly obvious that you can’t do all that on ToR switches, and need control of the virtual switch (the real network edge) to get the job done.

Yannis sent me an interesting challenge after reading my short “this is how I wasted my time” update:

We are very much committed in automation and use Ansible to create configuration and provision our SP and data center network. One of our principles is that we do rely solely on data available in external resources (databases and REST endpoints), and avoid fetching information/views from the network because that would create a loop.

You can almost feel a however coming in just a few seconds, right?

The featured webinar in March 2017 is the SDN Use Cases webinar describing over a dozen different real-life SDN use cases. The featured videos cover four of them: a data center fabric by Plexxi, microsegmentation (including VMware NSX), SDN-based Internet edge router built by David Barroso, and Fibbing - an OSPF-based traffic engineering developed at University of Louvain.

To view the videos, log into my.ipspace.net, select the webinar from the first page, and watch the videos marked with star.

It’s uncommon to find an organization that succeeds in building a private OpenStack-based cloud. It’s extremely rare to find one that documented and published the whole process like Paddy Power Betfair did with their OpenStack Reference Architecture whitepaper.

I was delighted to see they decided to do a lot of things I was preaching for ages in blog posts, webinars, and lately in my Next Generation Data Center online course.

Highlights include:

During the Tech Field Day Extra event at Cisco Live Europe 2017 Fabrizio Maccioni, Technical Marketing Engineer at Cisco, described enhanced programmability available in Cisco IOS XE release 16.x. What really got my attention was the claim that they made NETCONF on Cisco IOS transactional (and Fabrizio mentioned the candidate config and commit).

Here's my initial reaction:

I often get questions from engineers wondering whether my webinars or courses would be too tough for them. Here’s a question I got from an engineer who wanted to attend my Building Next-Generation Data Center course: “What specific prior experience do you expect for this workshop?”

Eyvonne Sharp wrote a great blog post describing Cisco’s love of complexity and how SD-WAN vendors proved things don’t have to be that complex.

I know Cisco (and every other vendor) loves making ever-more-complex solutions that lock you into their morass for the rest of your life (long-distance vMotion anyone?).

Matthias Luft (a good friend of mine, and a guest speaker in the upcoming Building Next-Generation Data Center course) wrote a great post about the (lack of) security in software development.

The parts I like most (and they apply equally well to networking):

Last year Cisco launched a new series of Nexus 9000 switches with table sizes that didn’t match any of the known merchant silicon ASICs. It was obvious they had to be using their own silicon – the CloudScale ASIC. Lukas Krattiger was kind enough to describe some of the details last November, resulting in Episode 73 of Software Gone Wild.

For even more details, watch the Cisco Nexus 9000 Architecture Cisco Live presentation.

Remember the OSPF NSSA Forwarding Address kludge and its consequences? Let’s figure out whether the nerd knobs available in Cisco IOS can save the day.

TL&DR: Don’t use OSPF areas if you can avoid them. Don’t use NSSA areas.