Category: OpenFlow

OpenFlow and SDN: Two Years after ONF Launch

Major vendors (with the exception of NEC) haven’t made any progress. Juniper still hasn’t delivered on its promises. Cisco still hasn’t shipped an OpenFlow switch or an SDN controller (although they’ve announced both months ago). Brocade supposedly has OpenFlow on their high-end routers and Arista supports OpenFlow on its old high-end switch (but not in GA EOS release).

Every major vendor is talking about SDN, but it’s mostly SDN-washing (aka CLI-in-API-disguise). Cisco is talking about OnePK, and has shipping early adopter SDK kit, but it will take a while before we see OnePK in GA code on a widespread platform.

Startups aren’t doing any better. Big Switch is treading water and trying to find a useful use case for their controller. Nicira was acquired by VMware and is moving away from OpenFlow. Contrail was acquired by Juniper and recently shipped its product (which has nothing to do with OpenFlow and not much with SDN). LineRate Systems was acquired by F5 and disappeared.

We haven’t seen customer deployments either. Facebook is doing interesting things (but from what I’ve heard they’re not OpenFlow-based), Google has an OpenFlow/SDN deployment, but they could have done the exact same thing with classical routers and PCEP, Microsoft’s SDN is based on BGP (and works fine).

It seems like the reality hit OpenFlow and it was a very hard hit… and according to Gartner we haven’t reached the trough of disillusionment yet.

add comment

Two and a Half Years after OpenFlow Debut, the Media Remains Clueless

If you repeat something often enough, it becomes a “fact” (or an urban myth). SDN is no exception, industry press loves to explain SDN like this:

[SDN] takes the high-end features built into routers and switches and puts them into software that can run on cheaper hardware. Corporations still need to buy routers and switches, but they can buy fewer of them and cheaper ones.

That nice soundbite contains at least one stupidity per sentence:

read more see 16 comments

Flow Table Explosion With OpenFlow 1.0 (And Why We Need OpenFlow 1.3)

The number of OpenFlow flows you can use in hardware switches is one of the major roadblocks in a large-scale OpenFlow deployment. Vendors often use hardware TCAM tables to match OpenFlow entries, and as those tables are expensive to implement in silicon, they tend to be small. Typical TCAM tables have a few thousand entries.

Is that good enough? As always, the answer depends on the use case, the network size, and implementation details. This blog post will focus on the last part.

TL&DR summary: Use switches that support OpenFlow 1.3.

read more see 9 comments

Forwarding Models in OpenFlow Networks

OpenFlow is a simple TCAM programming protocol, and can be used to implement any network forwarding paradigm as long as:

  • OpenFlow specifications include matches and actions (including rewrites) of the packet header fields used in the forwarding paradigm. For example, you cannot program SRv6 tunnels with OpenFlow because it’s not part of OpenFlow standard.
  • The forwarding hardware you want to use supports the OpenFlow matches and actions you need in your forwarding paradigm.
  • The forwarding paradigm does not use dynamic interfaces (example: MPLS-TE tunnels) or multipoint tunnel interfaces (example: VXLAN). OpenFlow was designed to be used on point-to-point physical interfaces and does not include interface management.

This blog post describes some of the more common OpenFlow use cases (assuming you want to use an obsolete rarely-implemented protocol).

read more add comment

Overlay Virtual Networks 101

My keynote speech @ PLNOG11 conference was focused on (surprise, surprise) overlay virtual networks and described the usual motley crew: The Annoying Problem, The Hated VLAN, The Overlay Unicorn, The Control-Plane Wisdom and The Ever-Skeptic Use Case. You can view the presentation on my web site; PLNOG organizers promised video recording in mid-October.

Just in case you’re wondering why I keep coming back to PLNOG: they’re not only as good as ever; they’re getting even more creative.

add comment

OpenFlow and Fermi Estimates

Fast advances in networking technologies (and the pixie dust sprinkled on them) blinded us – we lost our gut feeling and rule-of-thumb. Guess what, contrary to what we love to believe, networking isn’t unique. Physicists faced the same challenge for a long time; one of them was so good that they named the whole problem category after him.

Every time someone tries to tell you what your problem is, and how their wonderful new gizmo will solve it, it’s time for another Fermi estimate.

read more see 5 comments

Management, Control, and Data Planes in Network Devices and Systems

Every single network device (or a distributed system like QFabric) has to perform at least three distinct activities:

  • Process the transit traffic (that’s why we buy them) in the data plane;
  • Figure out what’s going on around it with the control plane protocols;
  • Interact with its owner (or NMS) through the management plane.

Routers are used as a typical example in every text describing the three planes of operation, so let’s stick to this time-honored tradition:

read more see 6 comments

Real-Life SDN/OpenFlow Applications

NEC and a slew of its partners demonstrated an interesting next step in the SDN saga @ Interop Las Vegas 2013: multi-vendor SDN applications. Load balancing, orchestration and security solutions from A10, Silver Peak, Red Hat and Radware were happily cooperating with ProgrammableFlow controller.

A curious mind obviously wants to know what’s behind the scenes. Masterpieces of engineering? Large integration projects ... or is it just a smart application of API glue? In most cases, it’s the latter. Let’s look at the ProgrammableFlow – Radware integration.

read more add comment

Implementing Control-Plane Protocols with OpenFlow

The true OpenFlow zealots would love you to believe that you can drop whatever you’ve been doing before and replace it with a clean-slate solution using dumbest (and cheapest) possible switches and OpenFlow controllers.

In real world, your shiny new network has to communicate with the outside world … or you could take the approach most controller vendors did, decide to pretend STP is irrelevant, and ask people to configure static LAGs because you’re also not supporting LACP.

read more see 6 comments
Sidebar