Q&A: Vendor OpenFlow Limitations

I rarely get OpenFlow questions these days; here’s one I got not so long ago:

I've just spent the last 2 days of my life consuming the ONF 1.3.3 white paper in addition to the $vendor SDN guide to try and reconcile what features it does or does not support and have come away disappointed...

You’re not the only one ;)

I was hoping I would have the ability to modify more L3 header fields. As it is, $vendor OpenFlow 1.3 implementation only allows me to modify the source and destination MAC addresses and VLAN tags as well as set the DSCP markings.

There are two reasons for that:

Hardware limitations – low-cost high-speed forwarding hardware doesn’t support all the packet mangling one would like to do. In particular, it’s hard to change IP addresses or port numbers to implement NAT or PAT. Changing MAC addresses is obviously easy, as that’s part of the regular inter-subnet forwarding pipeline, but even there some hardware implementations don’t allow you to change the source MAC address to any value but the MAC address of the outgoing interface (or maybe it’s just “suboptimal” software implementation).

Software limitations - some OpenFlow implementations from major vendors are plain ridiculous. Juniper used to be the worst of them all, and a few others are not far behind. For more details of what individual vendors support, watch the “OpenFlow Support” vendor-specific videos in my Data Center Fabrics webinar. 

Keep in mind that I update those videos once or twice a year, and although vendor OpenFlow support is moving at glacial speeds, do check the release notes as well.

I was really hoping for the ability to also modify the source and destination IP addresses as well (want to use $vendor hardware as high-speed NAT tool using OpenFlow). I have scoured the internet and can only find one vendor that makes a switch that allows me to at least modify the destination IP address. Is there literally no other switch that your aware of that can do this?

If you need a NAT tool at gigabit speeds, you’d be far better off using x86-based solution, for example something riding on Snabb Switch (Igalia made 4-over-6 tunneling work at 20 Gbps per core).

For terabit speeds you do need hardware solution, but there are only a few chipsets on the market that can do that, and their NAT table is probably tied to TCAM and thus pretty small. There are a few exceptions that use NPUs or yet-to-be-unveiled hardware riding on unicorn dust, but you might not like the price tag.

Finally, you might have to reformulate the problem (here’s an example of how you can do load balancing at scale). People doing load balancing with OpenFlow (or similar technologies) use anycast IP addresses on the servers with direct server return, like what Coho Data is doing for iSCSI/NFS traffic (for more details, watch the Network Services videos in my SDN Use Cases webinar).


  1. Hello Ivan,

    As you've remarked in one of your webinars, NoviFlow's NoviSwitches are the exception to the rule in having implemented the full openFlow 1.3 spec (and most of 1.4 and even parts of 1.5), at high capacity (up to 512 Gbps), at line rate even for 100 Gbps ports. We have also implemented a series of OpenFlow Experimenter extensions to provide many features not covered by the OpenFlow specifications to provide L2-L7 packet header AND payload matching and flow handling, BFD link monitoring , L2 and L3 VLAN support for GRE, VxLAN, MPLS and GTP, and built-in hashing and symmetric hash-of-fields, and then finally a whole slew of OAM oriented features such as TACACS+, RADIUS authentication, SNMP, full CLI, and even gRPC automated provisioning for large installations. Anyone interested in high-performance fully programmable SDN forwarding planes are invited to our website and check our our product specs to verify the above.
    1. Hi Marc,

      How about starting with "I'm VP of Marketing @ Noviflow using a third-party blog to promote my products" ;) Also, I did mention "exceptions using NPU", which is what NoviFlow is doing.
    2. I'm VP of Marketing @ Noviflow using a third-party blog to promote my products. So there! And thanks, Ivan, for generating this opportunity for me to do so!
  2. OpenFlow is practically dead. Maybe it will be revived after the ON.Lab merger... There is no serious disruptive device vendor.
    1. Disclaimer: I'm VP of Marketing @ NoviFlow a company that makes and sells fully-programmable, high-performance OpenFlow switches and solutions based on NPUs - the execution that Ivan mentions above. I have been involved in many new technologies during my career, and your perception of OpenFlow being dead is typical at this stage in the overall uptake cycle of any new technology (see Gartner's Hype Curves), so I understand what you're saying, but I don't agree your conclusion. As a vendor, in the last eighteen months we've seen a massive uptake OpenFlow based solutions being deployed around the world. Some of these, as with Telstra's PEN network, are public. I am also involved with the ON.Lab merger with the ONF - further disclaimer: I am the Director of the Market Area of the ONF. The reason we are doing this merger is to bring the specification development process closer to the Open Source projects which are driving the evolution of the specs as well as uptake of the specifications by users. Our intent is to leverage this model to accelerate both in a virtuous circle of design as a reaction to real-world user needs. As to your claim f no serious disruptive device vendor, here is a "market disruptor" report from Current Analysis about NoviFlow: http://noviflow.com/wp-content/uploads/Report_99245.pdf
    2. Dear Marc,

      NoviFlow is too small currently to make a real influence on the market. This may change in the future... :-)
      Let's see... :-)
    3. We also need some interoperability certifications. Current vendor statements are not good enough for network design. ONF is lagging behind in certifications and that makes life pretty difficult.
      Only the Chinese vendors take somewhat serious ONF certifications, but even that does not help much...
  3. Disclaimer: I'm (among other things) an R&D engineer for SW and ASICs @ HPE-Aruba, and I personally worked implementing OpenFlow in hardware. So, I'm shamelessly promoting something I worked on.

    If the use case is more about flexibility than raw performance, the latest generation of ASICs in the HPE-Aruba Campus product line (for Datacenter, as Ivan said, you may need to wait for some new ASICs coming out soon) has the ability of offer re-programable OF pipelines and a wide range of matches and transformations, using dedicated TCAMs and Hashes. Your performance millage may vary depending on your table and rule set.

    The "HPE Switch Software OpenFlow v1.3 Administrator Guide" has a section about "OpenFlow Custom pipeline" that provides all the technical details and constraints, so you can jump straight into the details and skip the marketing.

    1. Hi Diego,

      Nice to hear from you after a long while. For everyone else: we covered one of the programmable pipelines (not sure whether it's the same one Diego mentioned) in this podcast:

    2. Does such a guide also exist for HPE´s Comware based switches?
Add comment