In a practical demonstration of Software Defined Networking, HP showed attendees at the recent Interop New York 2014 conference how to use its OpenFlow SDN controller to select DNS request packets for validation by a DNS security application.
In this scenario, the SDN controller tells the SDN switch infrastructure to identify DNS requests by protocol and port number. The SDN switch infrastructure then forwards the requests to a security application for verification that they are valid, non-malware domain names. DNS validation is an easy way to help reduce the number of malware-infected enterprise clients. When someone clicks on a link to a malware site, a DNS request maps that domain name to one of several malware-infection controllers. Returning the IP address of a security server within the enterprise warns the user about the malware site, providing just-in-time education to the workforce as well as eliminating malware infections.
Chris Young, a technical marketing engineer, and Jeff Enters, chief network architect for the Technology Services team, presented the demonstration to the Networking Field Day team. Unlike most presenters, they used a whiteboard presentation. You can watch their presentation in the video below and read more about the demonstration on the Tech Field Day site.
This isn't the first time that HP has done a practical SDN demonstration. At the Open Networking Summit in April 2013, HP demonstrated the ability to dynamically apply QoS to an HP network infrastructure upon initiation of a Microsoft Lync video call (read my post, Handling Video in an SDN World). That simple QoS demonstration covered a key SDN function: dynamic control of the network. I referred to it as the "emergence of the truly agile network." HP also ran an app version of this demonstration named Network Optimizer. Since then, other companies have demonstrated similar functionality with their SDN products.
In its latest demonstration, HP included a dual controller implementation. However, when I asked about mechanisms to handle split-brain failures, the presenters told me that capability wasn't yet supported. Chris suggested that HP may have something to show on this next year. I wasn't trying to stump the presenter; what I was trying to get at was an understanding of the maturity of the OpenFlow SDN controller and how it handled possible failures.
One of the useful points of this demonstration was that it showed the speed with which the SDN implementation, in combination with the BlueCats DNS validation app, was able to handle many thousands of DNS requests per second (40,000 in the demo). This speed is quite reasonable for a local implementation. But to make it more interesting and practical, HP decided not to use a local DNS validation server. While the demonstration took place in New York, the DNS validation server was located in San Francisco, adding significant latency to the request-response transaction. Even with the added latency, clients saw little change in operation, which is what I would expect. Simply adding 100ms to an already long transaction would not typically be visible to anyone using the client for normal Internet access.
One of the interesting aspects of the demonstration is that the HP team had to engineer a solution that prevented the network and app from inspecting the packets multiple times. This happens because the DNS packet, identified by the edge switch, must be forwarded to the remote DNS security app. The network must make sure that the forwarded DNS packet is not selected for inspection any additional times. To address this issue, HP used tunnels between the edge switch and the DNS security app. Tunneling wouldn't work in a more scalable network, so the network would have to know not to inspect the DNS packet multiple times.
HP also is creating an SDN app store in which network-aware applications are made available to customers. For example, a BlueCats app could make its DNS validation server aware of the HP network and provide the functionality described above in a production environment.