Hybrid OpenFlow, the Brocade Way

A few days after Brocade unveiled its SDN/OpenFlow strategy, Katie Bromley organized a phone call with Keith Stewart who kindly explained to me some of the background behind their current OpenFlow support. Apart from the fact that it runs on the 100GE adapters, the most interesting part is their twist on the hybrid OpenFlow deployment.

The “traditional” hybrid OpenFlow model (what Keith called hybrid switch) is well known (and supported by multiple vendors): an OpenFlow-capable switch has two forwarding tables (or FIBs), a regular one (built from source MAC address gleaning or routing protocol information) and an OpenFlow-controlled one. Some ports of the switch use one of the tables, other ports the other. Effectively, a hardware switch supporting hybrid switch OpenFlow is split into two independent switches that operate in a ships-in-the-night fashion.

More interesting is the second hybrid mode Brocade supports: the hybrid port mode, where the OpenFlow FIB augments the traditional FIB. Brocade’s switches using hybrid port approach can operate in protected or unprotected mode:

  • Protected hybrid port mode uses OpenFlow FIB for certain VLANs or packets matching a packet filter (ACL). This mode allows you to run OpenFlow in parallel (ships-in-the-night) with the traditional forwarding over the same port – a major win if you’re not willing to spend money for two 100GE ports (one for OpenFlow traffic, another for regular traffic).
  • Unprotected hybrid port mode performs a lookup in OpenFlow FIB first and uses the traditional FIB as a fallback mechanism (in case there’s no match in the OpenFlow table). This mode can be used to augment the traditional forwarding mechanisms (example: OpenFlow-controlled PBR) or create value-added services on top of (not in parallel with) the traditional network.

The set of applications that one can build with the hybrid OpenFlow is well known – from policy-based routing and traffic engineering to bandwidth-on-demand. However, Brocade MLX has one more trick up its sleeve: it supports packet replication actions that can be used to implement behavior similar to IP Multicast or SPAN port functionality. You can use that feature in environments that need reliable packet delivery over UDP to increase the chance that at least a single copy of the packet will reach the destination.

I like the hybrid approach Brocade took (it’s quite similar to what Juniper is doing with its integrated OpenFlow) and the interesting new features (like the packet replication), but the big question remains unanswered: where are the applications (aka OpenFlow controllers)? At the moment, everyone (Brocade included) is partnering with NEC or demoing their gear with public-domain controllers. Is this really the best the traditional networking vendors can do? I sincerely hope not.


  1. PBR configuration management? Ok, that's pretty cool. But it sounds like something you could easily do with NETCONF on standard hardware.
  2. Ivan,
    You mentioned this is similar to what Juniper is doing w/ integrated OpenFlow. I read through both articles and they do seem to be pretty much the same. Which leads me to my question.

    How do they actually differ? Is the Brocade switch one or the other but not both modes at the same time? I see Juniper gives OF a route preference but it appears Brocade look into the OF FIB first-much like a default route or match, then regular processing.

    Thanks for the great articles!
    1. The way I understood Dave Ward's explanation (when he was still @ Juniper ;), Junos installs OpenFlow entries in RIB (whereas Brocade installs them in FIB), making it possible to treat them like any other route (including route redistribution into other protocols).

      When I see it working, I'll believe :D
    2. Ahh, subtle difference. Yes, seeing is believing. Thanks!
  3. Can someone please explain the difference between "Traditional Openflow" enabled port and "Openflow Hybrid enabled but Unprotected" port?
Add comment