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).