Pirmin Sidler read the stretched VSAN blog posts by Duncan Epping (intro, HA/DRS considerations, demo) and asked me what I think about stretched VSAN considering my opinions on long-distance vMotion.

TL&DR answer: it makes way more sense than long-distance vMotion. However…

Whenever I talk about the various definitions of SDN (ending with the “SDN provides an abstraction layer”), old-timers sitting quickly realize that the SDN products that you can deploy in real life aren’t that different from what we did in the past – an SDN controller is often just an overhyped glorified network services orchestration system.

OK, so why didn’t we have that same functionality for the last 20 years?

One of my readers stumbled upon blog post from 2011 explaining the potential implementations of VXLAN hardware gateways, and asked me if that information is still relevant.

I knew that I’d included tons of information in the Data Center Fabrics and VXLAN Deep Dive webinars, but couldn’t find anything on the web, so I decided to fix that in 2015.

One of the comments I got on my Lego Bricks & BFT blog post was “well, how small should those modular Lego bricks be?”

The only correct answer is “It should be Lego bricks all the way down” or (more formally) “Modularity is a concept that should be applied at every level of the architecture.”

Today let’s focus on how much easier the life would be if we could take apart the network operating systems instead of just watching them as glued-together Death Stars.

One of my readers recently pointed me to a blog post written by Andrew Lerner from Gartner describing the drawbacks of stretched VLANs.

TL&DR: He’s saying more-or-less the same things I’ve been preaching for years. Now I can put Blessed by Gartner logo on my blog posts ;), and you can use the report to sway your CIO.

TL;DR: Gabi Gerber from Data Center Interest Group Switzerland (DIGS) is organizing a day-long Data Center event on September 16th, and invited me (again) as the keynote speaker. Do drop by to discuss data center design and automation challenges.

How do you capture all the flows entering or exiting a data center if your core Nexus 7000 switch cannot do it in hardware? You take an x86 server, load nProbe on it, and connect the nProbe to an analysis system built with ELK stack… at least that’s what Clay Curtis did (and documented in a blog post).

Obviously I wanted to know more about his solution and invited him to the Software Gone Wild podcast. In Episode 39 we discussed:

Sometimes it seems like the networking vendors try to (A) create solutions in search of problems, (B) boil the ocean, (C) solve the scalability problems of Google or Amazon instead of focusing on real-life scenarios or (D) all of the above.

Bryan Stiekes from HP decided to do a step in the right direction: let’s ask the customers how complex their data centers really are. He created a data center complexity survey and promised to share the results with me (and you), so please do spend a few minutes of your time filling it in. Thank you!

A few days ago I had a nice chat with Christoph Jaggi about private and public clouds, and the mistakes you can make when building a private cloud – the topics we’ll be discussing in the Designing Infrastructure for Private Clouds workshop @ Data Center Day in Berne in mid-September.

The German version of our talk has been published on Inside-IT; those of you not fluent in German will find the English version below.

A friend of mine sent me an interesting problem:

I noticed recently that my IOS routers aren't sending ICMP (unreachable; frag needed) messages in response to too-big IPv4 multicast packets with DF-bit set. They're just dropping these packets silently, breaking PMTUD.

Unfortunately, that’s not a bug but a FAD (Functions-as-Designed).

My first ride with Uber was a love at first sight – the amount of friction they managed to remove from using-a-taxi process is unbelievable.

However, every love story eventually faces real-life issues, and what really matters is how you handle them at that point.

Robin Harris described an interesting problem in his latest blog post: while you can reduce the storage access time from milliseconds to microseconds, the whole software stack riding on top still takes over 100 milliseconds to respond. Sometimes we’re optimizing the wrong part of the stack.

Any resemblance to SDN in enterprises or the magical cost-reduction properties of multi-vendor data center fabrics is obviously purely coincidental.

A link on Bruce Schneier’s blog pointed me to the latest article by the truly awesome James Mickens, this time making great fun of security researchers. Exactly what you need with your coffee on a Saturday morning. Enjoy!

After introducing the concepts of Cumulus Linux in the Data Center Fabrics update session, Dinesh Dutt described the typical data center architectures implemented with Cumulus Linux and the lessons everyone should learn from large-scale web properties.

Henk left a wonderful comment on my SDN will not solve real-life enterprise problems blog post. He started with a bit of sarcasm:

SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

However, he thinks (and I agree) that this vision doesn’t make sense: