A while ago I wrote “vMotion over VXLAN is stupid and unnecessary” in a comment to a blog post by Duncan Epping, assuming everyone knew the necessary background details. I was wrong (again).

Recently I had a fantastic conversation with Erich Hohermuth, a networking engineer with an unusual hobby: he’s a professional firefighting instructor (teaching firefighters across the country how to do their job).

Volunteer fire departments are pretty popular in Central European countries, and so he’s not the only one on his team with that skillset. The (not so unexpected) side effect: these people are the best ones when it comes to fighting IT disasters.

Good news: In the last few months, almost all major data center Ethernet switching vendors (Arista, Cisco, Dell Force 10, HP, and Juniper) released documented GA version of OpenFlow on some of their data center switches.

Bad news: no two vendors have even remotely comparable functionality.

One of my readers sent me this question:

I have a data center with huge L2 domains. I would like to move routing down to the top of the rack, however I’m stuck with a load-balancing question: how do load-balancers work if you have routed network and pool members that are multiple hops away? How is that possible to use with Direct Return?

There are multiple ways to make load balancers work across multiple subnets:

Craig Matsumoto recently quoted some astonishing claims from Dell’Oro Group analyst Alan Weckel:

• Whitebox switches (combined) will be the second largest ToR vendor;
• Whitebox 10GE ports will cost around $100.

Let’s try to guestimate how realistic these claims are.

I wrote (and spoke) at length about layer-2 and layer-3 gateways between VLANs and overlay virtual networks, but I still get questions along the lines of “how will you connect legacy servers to the new cloud infrastructure that uses VXLAN?”

Initial OpenFlow hardware implementations used a simplistic approach: install all OpenFlow entries in TCAM (the hardware that’s used to implement ACLs and PBR) and hope for the best.

That approach was good enough to get you a tick-in-the-box on RFP responses, but it fails miserably when you try to get OpenFlow working in a reasonably sized network. On the other hand, many problems people try to solve with OpenFlow, like data center fabrics, involve simple destination-only L2 or L3 switching.

The Does Centralized Control Plane Make Sense post triggered several comments along the lines of “do you think there’s no need for OpenFlow?”

TL;DR version: OpenFlow is just a low-level tool; don’t blame it for how it’s being promoted… but once you figure out it’s nothing more than TCAM (ACL+PBR) programming tool, you’ll quickly find a few interesting use cases. If only we’d have hardware we could use to implement them; most vendors gave up years ago.

I’m slowly moving away from Feedburner, and started the process by creating a new web page listing all my content feeds.

Sounds great, right? Well, this isn’t how this particular yak shaving really started.

A friend of mine sent me a challenging question:

You've stated a couple of times that you don't favor the OpenFlow version of SDN due to a variety of problems like scaling and latency. What model/mechanism do you like? Hybrid? Something else?

Before answering the question, let’s step back and ask another one: “Does centralized control plane, as evangelized by ONF, make sense?”

A networking engineer was trying to persuade me of importance of hardware VXLAN VTEPs. We quickly agreed physical-to-virtual gateways are the primary use case, and he tried to illustrate his point by saying “Imagine you have 1000 servers in your data center and you manage to virtualize 80% of them. How will you connect them to the other 200?” to which I replied, “That doesn’t make any sense.” Here’s why.

We all know how IT marketing works – unless you exaggerate your claims at least as much as your competitors do (the activity politely called “Bulls**t bidding war” by Tom Nolle) you’re soon just a footnote in the IT history. However, you don’t have to use the same approach in technical conversations.

There are tons of SDN workshops, academies, and webinars out there, many of them praising the almost-magic properties of the new technologies, or the shininess of vendors’ new gadgets and strategic alliances. Not surprisingly, the dirty details of real-life deployments aren’t their main focus.

As you might expect, my 2-day workshop isn’t one of them.

During a recent NetOps-focused discussion trying to figure out where Puppet/Chef/Ansible/… make sense in the brave new SDN-focused networking world I made this analogy: “Puppet manifest is like Prolog, router configuration is like Java or C++.” It’s a nice sound bite. It’s also totally wrong.

As expected, ARIN wasn’t that far behind APNIC and RIPE in IPv4 allocations and is now down to the last /8. Maybe it’s time for the last denialists to wake up and start considering IPv6 (or not – consultants love panicking customers)… and the new IPv6 resources page on ipSpace.net might help you get IPv6-fluent (hint: don’t miss the must-read documents section).