If you’re an avid Kindle user, you can buy the Data Center Design Case Studies book on Amazon. Here’s the Amazon.com link, search should find it on most other Amazon marketplaces.

However, if you can survive reading the PDF version, please buy it straight off my web site. Here’s why:

Expect a significantly reduced blogging frequency ;)

Occasionally I get a question about some totally impossible implementation detail (example: can we use OpenStack OVS plugin on VMware to avoid buying NSX?). These questions are often coming from people who painted themselves into a corner and are now desperately looking for MacGyver’s shoelaces to pull themselves out.

It’s easy to blame the engineer who tries to do the obviously impossible, but it’s often not his fault – these days a lot of technical people get pulled into the game of Build a Cloud in Three Easy Steps.

For the second episode of Software Gone Wild I got a truly interesting guest: David Gee, a network engineer already working on numerous network programmability and orchestration deployment.

During our half-hour chat we couldn’t avoid the question of whether every networking engineer will become a programmer and David provided an interesting answer: you don’t have to program, but you’ll definitely have to start thinking more like a good programmer.

A reader sent me this question:

I am hearing a lot about API in reference to SDN. I do not have any software or programming background but would like to understand this API in practical way. Could you help me?

TL&DR: API is CLI for program-to-program communication

The Mice and Elephants is a traditional QoS fable – latency-sensitive real time traffic (or request-response protocol like HTTP) stuck in the same queue behind megabytes of file transfer (or backup or iSCSI) traffic.

The solution is also well known – color the elephants pink (aka DSCP marking) and sort them into a different queue – until the reality intervenes.

True old-timers might appreciate the analogies I got while writing the Network Infrastructure as Code article. Let’s start with “do you remember this thingy?”

Source: Wikipedia

If you recognized the state-of-the-art (in those days) box in the picture, you might be able to relate to this screenshot:

This is pretty close to some SDN architectures I was privileged to see in the last three years.

Source: strategic humor @ HBR

I was asked to do a presentation at the recent Slovenian NOG (SINOG) meeting. I did an SDN one at the previous meeting, making NFV the next obvious choice… but I decided to put an interesting spin on it and focused on virtual routers.

When I heard people talking about “networking infrastructure as code” I dismissed that as yet another Software-Defined-Everything one-controller-to-rule-it-all hype. Boy was I wrong.

Last September I received a peculiar tweet from Luke Gorrie pointing me to a software switch pushing 200 Gbps through an Intel server literally hours after I’d watched the Deutsche Telekom Terastream presentation, so I mentioned Luke’s Snabb Switch as a potential performance solution in an email to Ian Farrer… and before Ian managed to reply, Luke was already working for Deutsche Telekom.

Carlos Mendioroz sent me an interesting question about unnumbered interfaces in Cumulus Linux and some of the claims they make in their documentation.

TL&DR: Finally someone got it! Kudos for realizing how to use an ancient trick to make data center fabrics easier to deploy (and, BTW, the claims are exaggerated).

After the excellent IPv6 security presentation Eric Vyncke had @ 9th Slovenian IPv6 summit someone asked me: “Why is IPv6 first-hop security so complex? It looks like the developers of IPv6 protocol stack tried to make users anonymous and made everyone’s life complex while doing that.”

Well, he was totally surprised by my answer: “The real reason IPv6 first-hop security is so complex is the total mess we made of L2/L3 boundary.”

Tired of endless debates discussing trivial matters? You're not alone (bonus point: a few pop-up windows every mail client should have).

The “bring Amazon Web Services mentality back home” blog post generated the expected comments, from “developers have no clue about networking or network services” to “we went through the whole thing and failed badly.”

Well, even though it might have seemed so, I didn’t advocate letting the developers go unchecked, I was just pointing out that double standards make no sense.