Category: OpenFlow

The SDN industry probably considers me an old and grumpy naysayer (and I’m positive Mrs Y has a special place in their hearts after her recent blog post), so I tried really hard to find a real-life example where OpenFlow could be used to solve mid-market innovator’s dilemma to balance my usual OpenFlow and SDN presentation.

The OpenFlow zealots are quick to point out the beauties of the centralized control plane, and the huge savings you can expect from using commodity hardware and open-source software. What they usually forget to tell you is that you also have to reinvent all the wheels the networking industry has invented in the last 30 years.

NEC demonstrated multi-vendor OpenFlow network @ Interop Las Vegas, linking physical switches from Arista, Brocade, Centec, Dell, Extreme, Intel and NEC, and virtual switches in Linux (OVS) and Hyper-V (PF1000) environments in a leaf-and-spine fabric controlled by ProgrammableFlow controller (watch the video of Samrat Ganguly demonstrating the network).

Does that mean we’ve entered the era of multi-vendor OpenFlow networking? Not so fast.

One of the most pleasant surprises of the recent Interop show was the Tail-f's Network Control System (NCS). I “knew” Carl Moberg (of the NETCONF and YANG fame) for a long time and had the privilege to meet him in person just before the SDN Buyer's Guide panel that I co-hosted with Kurt Marko (who did an excellent job putting the buyer's guide together). Anyhow, what Carl presented during the panel totally blew me away.

Hatem Naguib claimed that “the NSX controller cluster is completely out-of-band, and never handles a data packet” when describing VMware NSX Network Virtualization architecture, preemptively avoiding the “flow-based forwarding doesn’t scale” arguments usually triggered by stupidities like this one.

Does that mean there’s no packet punting in the NSX/Open vSwitch world? Not so fast.

Operating systems are boring (for most people); it’s the applications that make everyone excited. SDN is no different. Controllers are boring – someone has to reinvent all the wheels that the networking vendors have been inventing for the last 30 years before you can develop the sexy stuff ... but not many people outside of ivory towers would start developing the (supposedly) sexy SDN apps until being sure the underlying platform will not disappear into thin air.

I did a major overhaul of my RIPE 65 SDN presentation prior to MENOG 12 meeting, including a more comprehensive overview of SDN-related technologies sorted by the networking device plane they operate on.

The Controller-Based Packet Forwarding in OpenFlow Networks post generated the obvious question: “does that mean we need some kind of Control-Plane Protection (CoPP) in OpenFlow controller?” Of course it does, but things aren’t as simple as that.

Like every recently designed fabric configuration/management platform, NEC ProgrammableFlow controller supports numerous configuration interfaces, including CLI, GUI, web-based configuration, REST API and OpenStack plugin. For more details, watch this part of the ProgrammableFlow Technical Deep Dive webinar.

One of the attendees of the ProgrammableFlow webinar sent me an interesting observation:

Though there is separate control plane and separate data plane, it appears that there is crossover from one to the other. Consider the scenario when flow tables are not programmed and so the packets will be punted by the ingress switch to PFC. The PFC will then forward these packets to the egress switch so that the initial packets are not dropped. So in some sense: we are seeing packet traversing the boundaries of typical data-plane and control-plane and vice-versa.

He’s absolutely right, and if the above description reminds you of fast and process switching you’re spot on. There really is nothing new under the sun.

Once you get rid of spanning tree and associated kludges (not too hard in OpenFlow-based networks), BUM flooding becomes your biggest enemy. NEC’s engineers implemented some interesting features in the ProgrammableFlow switches and controllers: rate-limiting of unknown unicast frames, flooding control, and ARP snooping (if only they’d go for ARP proxy).

OpenFlow is not exactly known for its quality-of-service features (hint: there are none), but as I described in the ProgrammableFlow Technical Deep Dive webinar NEC implemented numerous OpenFlow extensions in their edge switches and the ProgrammableFlow controller to give you a robust set of QoS features.

Virtual tenant networks are one of the best features of NEC ProgrammableFlow solution – you can build virtual layer-2 subnets (based on VLANs, edge ports or port/VLAN combos), connect them with a virtual router, and implement packet filters and traffic steering ... while treating the whole data center fabric as a single device.

Even better, the ingress edge switch performs all the operations you configure (ACLs, L2 lookup, L3 lookup, source/destination MAC rewrite), resulting in optimal end-to-end forwarding.

You’ve probably heard that the networking hardware vendors decided to pool resources to create an open-source OpenFlow controller. Just in case you’re wondering whether they lost their mind (no, they didn’t), here’s my cynical take.

The ProgrammableFlow Principles of Operations section of the ProgrammableFlow Technical Deep Dive webinar generated tens of questions from the audience – it took us almost 20 minutes to answer all of them (note: you might watch the answers after watching the section that triggered the questions).