Build the Next-Generation Data Center
6 week online course starting in spring 2017

Forwarding Models in OpenFlow Networks

A few days ago Tom (@NetworkingNerd) Hollingsworth asked a seemingly simple question: “OpenFlow programs hop-by-hop packet forwarding, right? No tunnels?” and wasn’t satisfied with my standard answer, so here’s a longer explanation.

Before we get started, keep in mind OpenFlow is just a tool that one can use (or not) in numerous environments. Tom’s question is (almost) equivalent to “C programs use string functions, right?” Some do, some don’t, depends on what you’re trying to do.

Point OpenFlow Deployments

Sometimes you can solve your problem by using OpenFlow on individual (uncoupled) devices. Typical use cases:

  • Edge security policy – authenticate users (or VMs) and deploy per-user ACLs before connecting a user to the network (example: IPv6 first-hop security);
  • Programmable SPAN ports – use OpenFlow entries on a single switch to mirror selected traffic to SPAN port;
  • DoS traffic blackholing – use OpenFlow to block DoS traffic as close to the source as possible, using N-tuples for more selective traffic targeting than the more traditional RTBH approach.
  • Traffic redirection – use OpenFlow to redirect interesting subset of traffic to network services appliance (example: IDS).

Using OpenFlow on one or more isolated devices is simple (no interaction with adjacent devices) and linearly scalable – you can add more devices and controllers as needed because there’s no tight coupling anywhere in the system.

Fabric OpenFlow Deployments

Most OpenFlow products being developed these days try to solve the OpenFlow fabric use case (because existing data center fabrics and Internet clearly don’t work, right?). In these scenarios the OpenFlow controller manages all the switches in the forwarding path and has to install forwarding entries on every one of them.

Not surprisingly, developers of these products took different approaches based on their understanding of networking challenges and limitations of OpenFlow devices.

Bypass the fabric. Some solutions (example: VMware NSX) bypass the complexities of fabric forwarding by establishing end-to-end something-over-IP tunnels, effectively reducing the fabric to a single hop.

Path-based forwarding. Install end-to-end path forwarding entries into the fabric and assign user traffic to paths at the edge nodes (aka Edge and Core OpenFlow). Bonus points if you’re smart enough to pre-compute and install backup paths.

If this looks like a description of MPLS LSPs, FECs and FRR, you’re spot on. There are only so many ways you can solve a problem in a scalable way.

The dirty details of path-based forwarding vary based on the hardware capabilities of the switches you use and your programming preferences. Using MPLS or PBB would be the cleanest option – those packet formats are well understood by network troubleshooting tools, so an unlucky engineer trying to fix a problem in an OpenFlow-based fabric would have a fighting chance.

Unfortunately you won’t see much PBB or MPLS in OpenFlow products any time soon – they require OpenFlow 1.3 (or vendor extensions) and hardware support that’s often lacking in switches used for OpenFlow forwarding these days. OpenFlow controller developers are trying to bypass those problems with creative uses of packet headers (VLAN or MAC rewrite comes to mind), making a troubleshooters job much more interesting.

Hop-by-hop forwarding. Install flow-matching N-tuples in every switch along the path. Results in an architecture that works great in PowerPoint and lab tests, but breaks down in anything remotely similar to a production network due to scalability problems, primarily FIB update challenges.

If an OpenFlow controller using hop-by-hop forwarding paradigm implements proactive flow installation (install N-tuples based on configuration and topology), it just might work in small deployments. If it uses reactive flow installation (punt new flows to the controller, install microflow entries on every hop for each new flow), it deserves a nomination for Darwin Award.

Why does it matter?

Would you buy a core router that only supports RIPv1? Would you use a solution that uses PBR instead of routing protocols? Would you use NetFlow-based forwarding with flows being instantiated by a central router (remember Multi-Layer Switching on Cat5000)? Probably not – we’ve learned the hard way which protocols and architectures work and which ones don’t.

OpenFlow is an emerging technology, and you’ll stumble upon numerous vendors (from startups to major brand names) selling you OpenFlow-based solutions (and pixie dust). It’s important to understand how these solutions work behind the scenes when evaluating them. Everything will work great in your 2-node proof-of-concept lab, but you might encounter severe scalability limitations in real-life deployment.

More information

It just so happens that I’m running an OpenFlow/SDN Use Cases webinar in a few weeks. It’s free, but make sure you register before we run out of space in the virtual classroom.


Post a Comment

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.