Last Wednesday I had the pleasure of meeting with Chris Young and Jeff Enters from HP Networking as part of Tech Field Day Extra! at Interop NYC 2014. Going into the discussion I had expected to get a presentation on HP’s newly launched (but previously announced) SDN App Store. Instead, Jeff and Chris turned off the projector, pulled over a whiteboard, and started drawing a network and explaining some of what they were doing with SDN on their own network, and specifically the part of the network that was related to Interop. Whiteboarding is always a good way to the hearts (and hopefully minds) of Tech Field Day delegates because it means no “NASCAR” slide and no Gartner quotes, both of which we understand companies wanting to share, but which are really aimed at a different audience; for the most part I think I can speak for the majority when I say that we don’t care what Gartner says or how many logos you can slap on a single slide, because what we want to hear is how good the solution is so we can make up our own minds. So with that out the way, what did they talk about?

TL;DR > They’re really using OpenFlow, and in a way I thoroughly approve. I’ll try and explain below.

The Scenario

The scenario given to us on the whiteboard is as follows:

Basically, HP have three data centers in this example – San Francisco (SFO), Denver (DEN) and EWR (Newark), shown across the top of the diagram, all interconnected with 1G links. Then there’s the “Warehouse” where they stage networks to be used at events like Interop, before they are shipped to site and deployed. The plan is that the staged network will look as much as possible like the final product, give or take perhaps some WAN elements. The bottom right of the diagram shows the Interop network, with 1G links back to the HP data centers.

The deployed network (in the Interop area) has a couple of HP 3800 switches acting as WAN aggregation (arguably not necessary), then another pair of HP 3800 switches which are really where the data is being manipulated. This second pair of HP 3800 switches are being managed by OpenFlow-speaking controllers located in the SFO data center which, if you know US geography, means that they are in the diagonally opposite corner of the country, so there is some unavoidable latency between the data plane and the controllers. To be clear – and we had to make sure – HP aren’t suggesting that this is how you should deploy your controllers, but in terms of proving the point that it – whatever “it” is – can be done, they win.

What Is “It” Then?

“It” is running an OpenFlow controller that’s located nowhere near the switches it’s controlling. If you’re concerned that having the 3800 switches querying every new flow with the controllers across the country is going to be unscalable and introduce unacceptable latency, then rest assured I share your concerns. However, that’s not quite what’s going on here. The 3800s are not running as pure OF switches, but rather are running in a hybrid mode where they still have a local control plane that is capable of making its autonomous forwarding decisions just like a regular switch. OpenFlow is only used to define – in fact mostly pre-define – the exceptions, and everything else will be processed by the regular forwarding tables.

Simple enough, right? So what kind of things might one add to the OpenFlow table? HP gave a couple of examples, the first of which involved DNS.

DNS Service Insertion

I’m not sure that HP actually called this process service chaining or service insertion, but that’s pretty much what their DNS examples amount to. If I recall correctly, there were two ‘tenants’ at Interop (HP and Bluecat) who needed two different DNS behaviors.

BlueCat

BlueCat have a product called “DNS Director” that looks for DNS queries being made to non-approved servers (i.e. external servers); the idea is to ensure that DNS tunneling and other threats are not present, and that clients are not being redirected to compromised DNS servers. DNS queries targeted at unknown servers are redirected to the BlueCat App running on the HP SDN Controller where the BlueCat DNS Director app is running. DNS Director can then redirect the response to a BlueCat DNS server where the packets are evaluated against policies and threat databases, and a response is sent back to the client (having been resolved by the BlueCat DNS servers) with a spoofed source address so that the client believes it got a legitimate response from the target server.

This is pretty simple to implement from an OpenFlow perspective – put in a rule that says “If it’s UDP/53 and the destination is not in this list of known servers, redirect to the controller.”

BlueCat’s product is one of the showcased applications in the HP SDN App Store and was being demonstrated at Interop.

HP

HP’s DNS application, part of the HP Sentinel Security Application, grabs DNS requests and runs them through a number of checks to make sure that the requests sites do not break policies, do not have bad reputation scores and so forth which I’m guessing ties in with the HP TippingPoint product capabilities. Like with the BlueCat solution, OpenFlow rules are put in place preemptively to redirect any DNS requests coming from clients, and redirecting them to the controller which in turn feeds the queries to the HP application. Once the application has completed its security and policy checks, the appropriate response can be returned.

Wait, What? Apps in the Controller?

Yes, apps on the controller. And they’re on the other side of the country, too, so latency is definitely a factor – but for DNS, will half a second kill things? Not ideal, and as I mentioned earlier, not recommended, but DNS is at least tolerant to small delays. If every packet in a telnet session were being redirected, I might have more to say about this. I guess I’d prefer to see the apps running independently and then sending their instructions (requests?) to the controller via one of those ubiquitous northbound API things we hear so much about. For now though, they’re located within the SDN Controller.

Two DNS Apps at the Same Time?

HP figured that they were going to have problems running two DNS applications in the same SDN controller; I guess it makes it difficult to determine which redirected packet should go to which application. For Interop therefore there were two controllers deployed in SFO, and together they controlled the same switches.

The HP 3800 switches had two DBIDs created, and VLANs were mapped into each DBID. Each DBID is configured so it knows which controller is allowed to control it, and thus it’s possible to have two controllers simultaneously configuring ports on the same switch – they don’t configure the same ports and VLANs. BlueCat demos were run from one DBID, and HP ran their demos from another DBID. Nice.

Lync

HP spent two years working with Microsoft to expose APIs that would allow Microsoft Lync and HP’s SDN controllers to talk to one another. With this integration in place now, when two Lync endpoints are about to connect to one another (with Lync having acted as the broker for the call), Lync notifies the SDN Controller about the endpoints and TCP/UDP ports involved in the call, and the HP Network Optimizer SDN Application then requests the controller to configure the 3800 switches with rules that match those parameters with an action to set DSCP in matching packets before letting the network pass them on. It could do more I suppose – you could redirect over a totally different path if you wanted – but this way you guarantee that DSCP is only applied and honored for calls set up by Lync itself. One can only assume that there is a similar call tear-down process too, though it was not explicitly discussed when we spoke.

This kind of integration is something we need to see more of, although I sincerely hope we see openly available communication busses to which any application (or controller) can subscribe. It would be great to be able to easily subscribe to a messaging buss on a Lync server, a VMWare server, Cisco UCS management, and so forth, and use that information to dynamically optimize the network traffic. I’m not clear whether the HP/Lync integration is open to others or not – I sure hope so, because the introduction of a lot of proprietary or restricted interfaces will, I believe, hold back the broader development of the SDN marketplace.

Scalability

The key to all of this as I said earlier is that HP is not trying to boil the ocean in OpenFlow terms. Or rather, the applications we discussed were not doing so. They simply requested that DNS requests were redirected to them – that’s a simple rule to deploy, and it will stay there until it needs to change for some reason. The DNS applications do not therefore need to make constant dynamic changes via OpenFlow. Similarly, the Lync application only makes a change using OpenFlow when a new call is set up (or torn down?). Beyond the specific application requirements, the switches do their own thing just like they’ve done for years. To me, this certainly seems like a scalable approach, although other applications could use the SDN capabilities in a very different way – that’s the joy, or danger, of the HP SDN App Store.

Open Standards

I didn’t get a chance to ask HP Networking how open this solution is in terms of using OpenFlow to program other OF-enabled switches (can I throw, say, a Pica8 into the mix?), or whether the solution is limited only to HP OF-enabled switches. I’m not going to guess either way, but if I can find the answer I’ll update this post (and if HP can comment, that would be great too!).

Obligatory Fear, Uncertainty and Doubt

I wouldn’t be doing my job if I didn’t raise the FUD around running your network based on software from an app store. If there’s a problem with the BlueCat DNS Director, is there any danger that you might see the same thing happening as we see in the server world so often where the OS vendor (HP in this case) and the software vendor (BlueCat) point fingers at one another saying it’s the other person’s fault. I’m not suggesting that this is likely – sorry BlueCat, for using you as an example here! – but the principal stands, and it’s something about which customers will likely want to have some assurances. When it’s broken, I want to know who I’m calling to fix it. I also did not have an opportunity to talk about App pricing, and whether there are ongoing maintenance / upgrade fees, or indeed what level of support is provided when you download (buy?) an app from the SDN App Store.

FUD Aside…

Putting aside my random unfounded fears about support issues, let’s be clear about this, HP is into some cool stuff. I’ve been at a loss for a while really to understand HP Networking’s marketing strategy or, rather, the apparent lack of; I have this sinking though unproven feeling that somebody may still be in the mindset that billboard in airports is how to sell it. When you think SDN, do you think HP?

Despite that, HP Networking have been quietly pushing out OpenFlow enabled switches across their entire range as I understand it, and have been working to get a functioning SDN solution to market as well as developing the SDN App Store strategy to provide functional off-the-shelf use cases to enhance your network. I like that. I’d like to dig deeper mind you, but it’s good to see the strategy coming to fruition with the launch of the SDN App Store and some healthy eating of the corporate dog food (good point there – is HP’s internal network fully SDN controlled yet?). In many ways, HP Networking is delivering something that many others are still talking about. They’re not alone in having controllable networks but I believe they’re the first to go down this particular path.

With that in mind, I’d like to share a quote from the movie Moneyball:

“I know you’ve taken it in the teeth out there, but the first guy through the wall — it always gets bloody. Always.”

It isn’t easy being first to market with something new. What if the market doesn’t decide to go your way? What if after all your work, somebody waltzes in and copies your concept for less money? The change of perspective that is driving innovation under the guise of Software Defined Networking is meaning that a lot of companies are having to take a leap of faith with the direction of their products. In HP Networking’s case, is the app store already totally filled with a wide range of awesome products? Of course not – that takes time. The point is though, this architectural model has been launched. To quote a well known business maxim, “Release Early, Release Often.” Translated into geek, this means you want to get a limited version of your ideal product completed well (not bad code, just keep the functionality under control), and get it to market as early as you can. Add the bells and whistles in version 2, and listen to the feedback from your customers; then keep releasing updates.

Either way, this version 1 is a pretty good start and it shows a lot of promise. Watch this space, and look out for flying brick dust.

Watch the HP Networking Presentation

Because Tech Field Day is awesome, this presentation was recorded and has been made available so you can play along at home. Check it out here:

Disclosures

I attended Interop as a delegate at the invitation of Gestalt IT, who ran this Tech Field Day Extra! event. The events are funded by the sponsoring vendors who “buy” time to talk to the delegates, and that money in turn funds my travel, accommodation and food while I am there. I am not paid to attend this event (I take vacation from work and do it on my own time), and I am not obliged to blog, tweet, or otherwise publicize any sponsor of the event. Further, when I do choose to publish content related to the event, I do so at my own discretion, and the content and opinions expressed are mine alone without any interference from any other parties.

Please see my general disclosures page for more information.