I had the great pleasure of co-presenting an innovative demonstration of an OpenFlow-based SDN application along with Indiana University at the recent SDN Showcase event.
Brocade partnered with the Indiana University GlobalNOC in developing the solution that led to this demonstration. Before I delve into the technical aspects of this demonstration, a bit about the Layer123 SDN Showcase event is in order.
While the Layer123 SDN & OpenFlow World Congress is in its third year, the ONF sponsored SDN Showcase event is in its inaugural year. This SDN World Congress is one of the most prominent industry events that is highlighting and demonstrating the emerging software-defined and software-driven era we are now in; which is now being referred to as the “New IP”. There were about 1300 attendee’s, 60+ exhibitors and over 140 speakers at this year’s event. We are clearly (once again) experiencing exciting times in networking!
Our demonstration was very well received and generated some interesting follow-on questions and discussions. It illustrated a real-life use case of an SDN-based “Science-DMZ” solution. If you are not familiar with the Science-DMZ architecture, it is being deployed in many campus networks that are connected to Research & Education Network (REN) backbones. The problem it solves is one of poor performance with security firewalls when it comes to processing large and long lived elephant flows. This is a well-documented performance limitation with existing firewall products; they just cannot keep pace with the 10GbE and 100GbE networks that are deployed today.
As shown in the diagram below, the solution includes multiple components. A Brocade MLXe router provides the border router function, with full OF v1.0 support. OF v1.3 is now available on the MLXe platform but this demonstration did not require any of the advanced features in v1.3. There is a traffic analytics app, a traffic management app and an open-source SDN controller.
By default, all the traffic in/out of the campus network is sent to the firewall. OpenFlow is used to mirror all the traffic that traverses the DMZ border router to a traffic analytics app. In this use case, the open-source BRO app was used as the traffic analytics app. Alternately, a sampling technology such as sFlow could be used in place of the OpenFlow mirroring action. Once the BRO traffic analytics app determines the “good” elephant flows (this determination is based on the enterprise security policies), it creates a white-list of those flows and sends those parameters to the traffic management app. In our demo, the traffic management app was developed by the GlobalNOC @ IU; this SDN app is called SciPass and is also available as open-source. SciPass then instructs the SDN controller to push OpenFlow rules to the MLXe border router to re-direct the approved elephant flows so that they are no longer processed by the firewall. This provides a firewall service bypass function.
The permitted elephant flows are now dynamically re-directed so that they are sent directly in/out of the campus and the firewall is no longer in the forwarding path. What makes this solution so relevant is that the currently deployed Science-DMZ architectures do not have this capability and in the currently deployed solutions, the HPC/Science LAN is no longer behind the firewall. The enterprise IT department has moved this LAN outside of the firewall to eliminate the performance problems associated with the firewall processing of the large flows. That eliminates the performance problem with the firewall but clearly creates a huge security exposure. It solves one problem while creating another. This SDN based solution provides a new Science-DMZ deployment model that eliminates the performance problem with the firewall while allowing the HPC/Science LAN to remain protected behind the firewall. It truly provides the best of both worlds!
The results of this solution are shown here.
There are three transfers being shown. The lower black line shows the performance of a large flow when the firewall is in the forwarding path. As you can see, the performance is very bad. The middle green line shows the greatly improved performance provided by this solution; where it takes roughly 64ms for the BRO traffic analytics app to detect the “good” flow and after roughly 1.5s, the forwarding performance of the flow equals the rate of a flow with no firewall in its path, which is shown in the upper blue line. Pretty impressive results, huh?
So, that was the demo we presented at the showcase event but before I close this blog I’d like to point out a few other interesting take-away’s from the conference. One being that many of the speaker presentations included references to the OpenDaylight project and it is becoming evident that OpenDaylight is quickly becoming the industry’s de-facto SDN controller. And as you might have heard, Brocade will be shipping our SDN controller very soon and this controller is based on OpenDaylight. Another interesting take-away is that besides the Google OpenFlow/SDN deployment, not everyone is familiar with the OpenFlow/SDN deployment at Internet2. The Indiana University GlobalNOC team manages this SDN network for Internet2 and it is quite an advanced SDN deployment that has been in production for about 3 years now, runs on a nationwide 100GbE MLXe WAN backbone and fully leverages the capabilities of OpenFlow!
Well, I hope this short blog provides a glimpse into the conference and illustrates the SDN-based application that we jointly presented with IU. I must give a “shout-out” to our partner team at IU/GlobalNOC who helped drive and deliver this demo! Oh and I should also mention that this solution will soon be deployed in production, so it provides a clear example of SDN and OF solving a real problem in an elegant, automated and programmatic fashion.