From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

The Ethernet Switching Landscape – Part 08 – SDN & OpenFlow

1,539 Words. Plan about 10 minute(s) to read this.

This is one of a multi-part series on the Ethernet switching landscape I wrote to support a 2-hour presentation I made at Interop Las Vegas 2014. Part 1 of this written series appeared on NetworkComputing.com. Search for the rest of this series.

Ethernet switches have been a focal point of software defined networking. As some early SDN use-cases have centered on the data center, this makes sense. For those organizations who which to automate data center deployments or make traffic forwarding decisions that are off the beaten paths of traditional BGP* and OSPF, SDN offers a framework to get those tasks done. If you’re not clear on what software defined networking is, you might like to search for some of the content I’ve created about SDN.

As you evaluate an Ethernet switch, whether that’s a switch you already own or one you’re considering, there are two important questions to ask related to SDN.

  1. “Is this switch software definable”? Or put more succinctly, “Is this switch programmable?”
  2. “In what way is this switch programmable?”

Those are both seemingly simple questions with complex answers. The reason is that SDN describes a big idea, but is not a specific protocol or standard. For example, as a vendor I could choose to stretch the definition of SDN and claim that my switch is programmable because of its SNMP capabilities. Or, I could rightly claim that my switch is programmable because it has a rich, published API that can be written to in Java and Python. Those two descriptions (SNMP vs. API) are rather different things. I use that extreme example to show that SDN means different things to different vendors and marketing folks sometimes say what they must. Therefore, the potential buyer must ask specific questions to determine what the actual SDN capabilities of a switch might be.

SDN on Ethernet switches is a bit of a walk in the woods right now. There's a path, but it's not exactly obvious where you'll come out.

The SDN capabilities of Ethernet switches is a bit of a walk in the woods right now. There’s a path, but it’s not obvious where the path will ultimately lead.

SDN Features To Look For

Here is a list of SDN-related features worth looking for as you evaluate Ethernet switches. These features may or may not be important to your specific environment; I’ll do my best to explain the value of each feature and its significance overall to help you judge.

1. OpenFlow. OpenFlow is a southbound (SDN controller down to switch) protocol used to program a switch to perform specific actions on specific flows. Actions are things such as “forward out port X” or “drop.” A wide variety of match criteria allow for granular identification of flows. The complexity of OpenFlow has grown with each release, which moved fairly rapidly through OF1.0, 1.1, 1.2, and 1.3. The release of OF1.4 came a bit later, but is the latest published specification. The OF1.3 train is still seeing new revisions.

OpenFlow has proven challenging for hardware vendors to implement in existing silicon. Not all OpenFlow operations map well to switch ASICs, and thus some OF operations are punted to the switch’s general purpose CPU normally used for the control-plane, where forwarding performance takes a substantial hit. This contributes to the reasons the Open Networking Foundation (ONF) has slowed releases of official OF specifications. In addition, the ONF has established the Forwarding Abstractions Working Group, whose goal is to make it easier for vendors to implement OpenFlow in their hardware.

For the Ethernet switch buyer, OpenFlow is a bit of a conundrum. Support for OpenFlow is not ubiquitous across the industry. Those vendors that have added OpenFlow support to their switches don’t always support the latest specification. And when a specific OpenFlow version is supported, not all operations are able to be performed in hardware. Which operations can be performed in hardware and which ones cannot vary from switch to switch and vendor to vendor. Therefore, a buyer who wishes to leverage OpenFlow needs to understand the SDN application they wish to implement, how that application uses OpenFlow, and at what scale specific OpenFlow operations are required. Results will vary widely by hardware platform.

Stepping back to a more general point of view, OpenFlow is not at this time a “must have” for Ethernet switch buyers. That said, be aware that a number of SDN controllers can use OpenFlow as a way of programming switch forwarding behavior. Also, some switch vendors emphasize their OpenFlow capabilities heavily (HP, Big Switch, Pica8) while others de-emphasize OpenFlow in favor of other options. The real question becomes one of individual requirements. OpenFlow’s ultimate future is hard to predict.

I feel it’s important to point out that while OpenFlow might seem confusing in the context of Ethernet switches due to the varying support levels, it has a great story to tell in the realm of soft (virtual) switches. OpenFlow does quite well programming certain virtual switches embedded in hypervisors (like Open vSwitch), and can scale effectively on x86 hardware.

2. OVSDB. Somewhat related to OpenFlow is the Open vSwitch Database management protocol, OVSDB. If OpenFlow manages flow tables on hardware and software switches that support it, OVSDB is a framework protocol that could conceivably be used for many things, but whose primary task is to manage instances of Open vSwitch (OVS) and related functions that OpenFlow and of-config can’t perform.

You might be rightly thinking that OVS is a software switch. So what does OVSDB have to do with hardware Ethernet switches? One answer is that some hardware switches are capable of running OVS. And if you want to manage that hardware switch like you do your virtual switches, OVSDB is a compelling tool. Another answer is that OVSDB can be used as the configuration tool for other things, such as VXLAN Tunnel Endpoints (VTEPs) in hardware switches. For example, my understanding is that VMware NSX uses OVSDB to configure VTEPs, so hardware switches that support OVSDB are better poised to integrate with this environment.

3. VXLAN Tunnel Endpoint (VTEP). VXLAN is an overlay protocol that is used in data centers for network virtualization. Like any tunneling protocol, VXLAN has an encapsulation and decapsulation process. Take an Ethernet frame, stick a VXLAN wrapper around it, send it where it needs to go, take the wrapper off, and deliver the frame. In the context of Ethernet switches, a VTEP-capable switch means that the encap/decap operations can be performed at scale. While I don’t consider this an SDN capability as such, VXLAN is tied to SDN and network virtualization so closely that it seemed important to point the feature out.

4. Programmability. I somewhat belabored this point earlier, so I won’t park here long. But when evaluating an Ethernet switch, how the switch can be configured is the big concern. Ideally, the switch will fit into a customer’s fully automated IT environment by offering APIs. These APIs will allow software developers to write code that provisions the network as an entire entity. The savvy buyer will ask what sorts of APIs are offered and whether or not those APIs are published. Notably, not all vendor APIs are consumable by the general public, because the vendor might only open them up to partners or other carefully selected folks. If being able to consume the APIs yourself is important, make sure you understand whether or not that’s possible. The very best vendors will not only make their APIs public, but will also offer robust documentation and potentially consulting or engineering services to help you achieve your goals.

The Big Challenge

Remember that with Ethernet switches and SDN, the capabilities vary widely. To help keep this issue in perspective, consider that SDN is a foundational technology. SDN allows consumers to do things with their networks that were not previously possible (at least not easily) with traditional networking approaches. Therefore, if there is a specific network application you wish to run that relies on an SDN foundation, you need to find switches that support that application. That’s your big challenge. Understand the application. Understand what that application expects to be underneath it. Then go ahead and take a look at switches that can work for you.

Another important point to consider is that it’s not wise to assume that incumbent networking vendors will meet your SDN needs. While Cisco, Juniper, HP, Huawei, etc. might have exactly what you’re looking for in the SDN & Ethernet switching space, there are many competitors worth looking at who tend to be at the cutting edge. These competitors aren’t constrained by existing business models, and therefore have the luxury of going in whatever technology direction is the most beneficial to their end customers. Therefore, don’t make the mistake of assuming the big guys have all the answers when it comes to SDN. They have a lot of answers to be sure, but smaller vendors in this space are absolutely worth your time and effort to investigate. For example, consider Arista, Big Switch, Mellanox, NEC, Plexxi, Cumulus, Pica8, and Pluribus. All of them are lesser-known Ethernet switch vendors doing absolutely fascinating things that I promise will challenge the way you think about building data center networks.


*Note that BGP is being used to do a number of interesting things in the SDN realm. Have a listen to Packet Pushers Show 164 for one example.