Category: OpenFlow

A while ago I explained why OpenFlow might be a wrong tool for some jobs, and why centralized control plane might not make sense, and quickly got misquoted as saying “controllers don’t scale”. Nothing could be further from the truth, properly architected controller-based architectures can reach enormous scale – Amazon VPC is the best possible example.

Overlay virtual networks were the first commercial-grade OpenFlow use case – Nicira’s Network Virtualization Platform (NVP – rebranded as VMware NSX for Multiple Hypervisors after the acquisition, and finally rearchitected into VMware NSX-T) used OpenFlow to program the hypervisor virtual switches (Open vSwitches – OVS).

OpenStack is using the same approach in its OVS Neutron plugin, and it seems Open Daylight aims to reinvent that same wheel, replacing OVS plugin running on the hypervisor host agent with central controller.

Does that mean one should always use OpenFlow to implement overlay virtual networks? Not really, OpenFlow is not exactly the best tool for the job.

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.

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.

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?”

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.

Distributed DoS mitigation is another one of the “we were doing SDN without knowing it” cases: remote-triggered black holes are used by most major ISPs, and BGP Flowspec was available for years. Not surprisingly, people started using OpenFlow to implement the same concept (there’s even a proposal to integrate OpenFlow support into Bro IDS).

For more details, watch the Distributed DoS Prevention video recorded during the Real Life OpenFlow-based SDN Use Cases webinar.

An interesting startup is launching their SDN solution @ Interop Las Vegas today: Quantum Networks use the latest quantum computing technology to solve some of the hardest problems of controller-based networking.

One of the fundamental problems of hardware-based OpenFlow solutions is the flow update rate – most switches using merchant silicon can insert around 1000 new flows per second into their forwarding tables. Technologies based on quantum mechanics effects change all that – a quantum entanglement technology patented by Quantum Networks can install new flows instantaneously across the whole network.

Talking about OpenFlow (and poking holes in it) is fun, but are there any real-life deployments (apart from highly-publicized Google’s internal network)? I tried to describe a few of them in my SDN 101 webinar.

Microsoft is using tap aggregation network in production, and I forgot to mention OpenFlow-based New Zealand IXP.

Watch the video