During one of my SDN workshops, an attendees asked me “How do you build carrier-grade (5 nines) cloud infrastructure with VMware NSX?”

Short answer: You don’t… and it’s a wrong question anyway.

A while ago I started discussing the intricate technical details of fibbing (an ingenious way of implementing traffic engineering with traditional OSPF) with Laurent Vanbever and other members of his group, and we decided to record a podcast on this topic.

Things never go as planned in a live chat, and we finished talking about another one of his projects – software defined Internet exchange point (SDX), the topic of Episode 41 of Software Gone Wild.

A year ago I was a firm believer in the unlimited powers of Software-Defined Data Centers and their ability to simplify workload migrations. After all, if you can use an API to create any data center object, what’s stopping you from moving the workload running in a data center to another location.

As always, there’s a huge difference between theory and reality.

I got into an interesting discussion with a fellow networking engineer trying to understand the impact of a switch failure in a L2/L3 data center fabric (anything from Avaya’s fabric or Brocade’s VCS Fabric to Cisco’s FabricPath, ACI or Juniper’s QFabric) on MAC and ARP tables.

Here’s my take on the problem – have I missed anything?

In a recent blog post Tom Hollingsworth made a great point: we should refocus from fighting one fire at a time to preventing fires.

I completely agree with him. However…

Dinesh Dutt started his part of the Data Center Fabrics Update webinar with “what is Cumulus Linux all about” and “what data center architectures does it support” and then quickly jumped into details about the base technologies used by Cumulus Linux: MLAG and IP routing.

Not surprisingly, the MLAG part generated tons of questions, and Dinesh answered all of them, even when he had to say “We don’t do that.”

If you’ve been a networking engineer (or a sysadmin) for a few years, you must be pretty familiar with DHCP and might think you know everything there is to know about this venerable protocol. So did I… until I read the article by Chris Marget in which he answers two interesting questions:

• How does the DHCP server (or relay) send DHCP offer to the client that doesn’t have an IP address (and doesn’t respond to ARP)?
• How does the DHCP client receive the DHCP responses if it doesn’t have an IP address?

When I wrote my stretched VSAN post, I thought VSAN uses asynchronous replication across WAN. Duncan Epping quickly pointed out that it uses synchronous replication, and I fixed the blog post.

The “What about latency?” question immediately arose somewhere in my subconscious, but before I could add that thought to the blog post, Anders Henke wrote a lengthy comment that totally captured what I was thinking, so I’m including it in its entirety:

One of my subscribers asked me: “My subscription is valid till early December. How could I renew it now (due to budgetary reasons)?”

While I already had the process to do just that, there was no link that one could use (you had to know the correct URL). I’ve fixed that – you’ll find the renewal link on the first page of my.ipSpace.net

Another week, another story from the SDN land, this time The Register reporting on AT&T plans. Even though there are almost no details in the story, the headline boasts that “SDN is eating vendors’ lunch”, prompting SDN hopefuls on LinkedIn groups to claim that “the promise of SDN is fast coming to fruition.”

Not so fast.

When I asked “Are there any truly QoS-aware routing protocols out there?” in one of my SD-WAN posts, Marcelo Spohn from ADARA Networks quickly pointed out that they have one – Dynamic Link-State Routing Protocol.

He also claimed that DLSP has no scalability concerns – more than enough reasons to schedule an online chat, resulting in Episode 40 of Software Gone Wild. We didn’t go too deep this time, but you should get a nice overview of what DLSP is and how it works.

::: jump-link Enjoy the podcast :::

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.