Initial OpenFlow hardware implementations used a simplistic approach: install all OpenFlow entries in TCAM (the hardware that’s used to implement ACLs and PBR) and hope for the best.

That approach was good enough to get you a tick-in-the-box on RFP responses, but it fails miserably when you try to get OpenFlow working in a reasonably sized network. On the other hand, many problems people try to solve with OpenFlow, like data center fabrics, involve simple destination-only L2 or L3 switching.

Problems that can be solved with destination-only L2- or L3 switching are so similar to what we’re doing with traditional routing protocols that I keep wondering whether it makes sense to reinvent that particular well-working wheel, but let’s not go there.

The switching hardware vendors realized in the last months what the OpenFlow developers were doing and started implementing forwarding optimizations – they would install OpenFlow entries that require 12-tuple matching in TCAM, and entries that specify only destination MAC address or destination IP prefix in L2- and L3 switching structures (usually hash tables for L2 switching and some variant of binary tree for L3 switching). The two or three switching tables would appear as a single OpenFlow table to the controller, and the hardware switch would be able to install more flows. Quite ingenious;)

The vendors using this approach include Arista (L2), Cisco (L2), and Dell Force 10 (L2 and L3). HP is using both MAC table and TCAM in its 5900 switch, but presents them as two separate tables to the OpenFlow controller (at least that was my understanding of their documentation – please do correct me if I got it wrong), pushing the optimization challenge back to the controller.

More informations

The Data Center Fabrics webinar and SDN workshop include information on OpenFlow support offered by major data center switching vendors.