NEC and a slew of its partners demonstrated an interesting next step in the SDN saga @ Interop Las Vegas 2013: multi-vendor SDN applications. Load balancing, orchestration and security solutions from A10, Silver Peak, Red Hat and Radware were happily cooperating with ProgrammableFlow controller.

A curious mind obviously wants to know what’s behind the scenes. Masterpieces of engineering? Large integration projects ... or is it just a smart application of API glue? In most cases, it’s the latter. Let’s look at the ProgrammableFlow – Radware integration.

Here’s a slide from NEC’s white paper. An interesting high-level view, but no details. Radware press release is even less helpful (but it’s definitely a masterpiece of marketing).

Fortunately Ron Meyran provided more details on Radware blog as did Lior Cohen in his SDN Central Demo Friday presentation:

• DefenseFlow software monitors the flow entries and counters provided by an OpenFlow controller, and tries to identify abnormal traffic patterns;

• The abnormal traffic is diverted to Radware DefensePro appliance that scrubs the traffic before it’s returned to the data center.

Both operations are easily done with ProgrammableFlow API – it provides both flow data and the ability to redirect the traffic to a third-party next hop (or MAC address) based on a dynamically-configured access list. Here’s a CLI example from the ProgrammableFlow webinar; API call would be very similar (but formatted as JSON or XML object):

Why is this useful?

Deep packet inspection is CPU-intensive and hard to implement at high speeds. DPI products and solutions (including traffic scrubbing appliances like DefensePro) thus tend to be expensive. 40Gbps of DefensePro DPI (DefensePro 40420) sets you back almost half a million dollars (according to this price list).

Doing initial triage and subsequent traffic blackholing in cheaper forwarding hardware (programmed through OpenFlow) and diverting a small portion of the traffic through the scrubbing appliance significantly improves the average bandwidth a DPI solution can handle at reasonable cost.

Is this something only OpenFlow could do?

Of course not – flow monitoring and statistics have been available for decades, either in Netflow or sFlow format. Likewise, we’ve been using PBR to redirect traffic for decades, and configuring PBR through NETCONF is not exactly rocket science ... and of course there’s FlowSpec that real-life engineers sometimes use to mitigate real-life DoS attacks (although, like any other tool, it does fail every now and then).

However, an OpenFlow controller does provide a more abstracted API – instead of configuring PBR entries that push traffic toward next hop (or an MPLS TE tunnel if you’re an MPLS ninja) and modifying router configuration while doing so, you just tell the OpenFlow controller that you want the traffic redirected toward a specific MAC address, and the necessary forwarding entries automagically appear all across the path.

Finally, there’s the sexiness factor. Mentioning SDN instead of Netflow or PBR in your press release is infinitely more attractive to bedazzled buyers.

Will it scale?

You should be aware of the major OpenFlow scaling issues by now, and I hope you’ve realized that real-life switches have real-life limitations. Most of the existing hardware reuses ACL entries when you ask for full-blown OpenFlow flow entries. Now go and check the ACL table size on your favorite switch, and imagine you need one entry for each flow spec you want to monitor or divert to the DPI appliance.

Done? Disappointed? Pleasantly surprised? Do share your feelings ;)

However, a well-tuned solution using the right combination of hardware and software (example: NEC’s PF5240 which can handle 160.000 L2, IPv4 or IPv6 flows in hardware) just might work. Still, we’re early in the development cycle, so make sure you do thorough (stress) testing before buying anything ... and just in case you need rock-solid traffic generator, Spirent will be more than happy to sell you one (or few).

Update 2013-07-06: replaced diagram from NEC's slide deck with a more detailed diagram from NEC's whitepaper