I’ve just got back from Networking Field Day 9 (NFD9) and my head is buzzing after a busy week of presentations. I posted a preview of NFD9 so it seems only fair to give a quick wrap up of the week’s themes and presentations as I saw it.

My NFD9

After some time spent thinking on the flights back home, I came to the conclusion that there were two themes that were recurring this week.

The dominating theme for me was, at last, seeing the magic rainbow-expelling problem-solving unicorn that is Software Defined Networking – SDN – and all its inherent paradigm-shifting magic, turned into products that actually seem real, and are starting to deal with some of the issues that were flagged up when SDN was first being described. It’s relatively easy to SDN-wash a product, but making it something from which a user can actually benefit, well, that’s something else.

The second theme was that many of the products looked to the concept of detecting or fixing problems before the users were aware of them, whether as an alert from a monitoring system, or a network that automatically self-heals or otherwise avoids problem areas.

SDN == Programming

Don’t get me wrong, there’s still a long way to go. The idea that SDN means networking engineers have to be Python programmers persists in the minds of many and, sadly, the products of many as well. Even just a year ago, the first thing we were being told about any SDN-compliant product was what APIs it supported. Is it RESTful? XML RPC? Does it support OpenFlow fully? Bottom line: we (the sane) are not going to be writing code to program every single flow on a switch using OpenFlow. I believe what we really want is products that support standardized interfaces, yes, but only because we like the idea that somebody other than the product vendor might be able to do a better job of controlling that device.

The Bare Essentials

This idea extends into bare metal / white box switching where we are seeing separation of hardware from software at the device level; buy your switch from one vendor, and your operating system from another. Then if the software you installed on that switch supports programmability via a standard interface, you can manage it with a controller provided by somebody else. Would we have one controller for the entire network? There’s no reason to do so, and arguably it may be better to find somebody who makes a great data center controller, then use somebody else for your WAN controller. Most importantly, and let’s be clear about this, I believe that the majority of us:

• Do not want to program our own controller, thanks;
• Do not want to have to be a programmer to manage the controller we bought.

I know that there’s no problem that can’t be solved if you abstract it sufficiently (corollary: any problem can be solved in Perl through the judicious application of hashes), but I’m not sure I want to be the one doing the abstraction in most environments. I’d like to have the option to do so, but I also need something that works out of the box too.

Those NFD9 Vendors

That brings me rather neatly back to what we saw this week at NFD9. Here’s a brief look at a few high points.

SDN WAN

If you were wondering what that was, you aren’t alone. I’ll dig into more detail in future posts, but this week we saw two key, and different approaches:

VeloCloud

VeloCloud offer a dynamic WAN with smart traffic control, multi-link load balancing, QoS and improved performance with lower packet loss over the WAN. The solution is hardware and cloud-based, and reliant on VeloCloud to function, and VeloCloud also provide a cloud-based Internet gateway as part of the subscription. Pleasantly, VeloCloud seem to be making the magic happen automatically, using their cloud-based core controller to manage the WAN flows, and on-site VeloCloud hardware as the edge.

CloudGenix

CloudGenix also offer a dynamic WAN with smart traffic control, multi-link load balancing, QoS and improved performance. The CloudGenix solution, ironically, is not cloud-based, and instead offers the edge routers and and core controller either as an x86 appliance or as a VM that can run on standard x86 hardware provided by the customer. Again, the controller does magical WAN things to manage the WAN flows which is a nice thing because there’s some pretty complicated analyses going on.

Hmm, Magical Clouds…

Both CloudGenix and VeloCloud perform wand-waving magic within their controllers, based on all sorts of measurements and statistics, in order to make what they consider to be the best decision to optimize WAN performance. Can I see behind that curtain? A little, sure, but to some extent we are trusting these companies to do it right. The proof is absolutely in the pudding, as the saying has it, and I suspect that if it works well, nobody’s going to worry too much about it. Both of these companies are using SDN principals to give us much better WAN performance, ideally suited to the logical hub and spoke topology that so many enterprises rely upon today (though they’re by no means limited to hub-spoke connectivity). They’re playing in an area currently deployed as a mix of MPLS, DMVPN and similar, but making it better. To me this is exactly where “SDN” can start building credibility, and it didn’t require a single line of Python from the customer to make it happen; CloudGenix and VeloCloud did the hard work for us. Hooray!

SDN Switching

Cumulus

Cumulus Networks showed off their switch OS which runs on a variety of white box and bare metal switch hardware. Cumulus are unashamedly faithful to the principals of unix (linux in this case) , building Layer2/Layer3 functions on top of the Cumulus OS, and allowing you choices on the way there. Don’t like Quagga for your routing? No problem, run Bird instead. The downside to this flexibility is that the lacking piece, and a potential hesitation point for adoption, is that to get a switch up and running and with the ports configured properly even at layer 2, means making changes to a number of different files in the shell (hostname in one place, ntp servers in another, interface configuration in another, and so forth). Should they combine them all into a single place? Probably not, but offering a quick-start abstraction layer is, I think, what people want and need right now in order to take this jump right now.

NEC Networks

NEC love OpenFlow and were early adopters of the technology; I believe they released the first OF1.0 and 1.3 switches to market. NEC’s ProgrammableFlow technology leverages OpenFlow to program switches, and their product really is the controller rather than the end point hardware, although they do sell switches as well if you want them. The use of OpenFlow means that if you can provide a compatible OF-compliant switch, the controller can program it. The controller provides some really quite nice visual abstractions which, while they may not scale as nicely in a really big network, on a reasonably sized network provide a really helpful view of what’s going on both on a logical and physical level. Again, the abstraction masks the complexity behind the scenes and removes the need for programming by the end user.

Pluribus Networks

Pluribus talked about their server switch network fabric product and its built-in network analytics. The availability of a fully capable server and storage connectivity within the switch opens up a number of options for Top Of Rack functionality combined with the simplicity of a network that appears (abstracted) as a single big switch. AppCito, a Pluribus partner, presented their “App-Aware Network” where they use the server capabilities in the Pluribus switches to add Network Functions Virtualization services right in the rack as a distributed Services Data Plane. In true NFV fashion, an application or traffic class can be defined, then various services defined to be applied to those flows – e.g compression, load balancing, Web Application Firewall, Caching and so forth. The Web UI for this is very clean and simple and is a very elegant abstraction of the underlying complexity of dynamically spinning up these services and programming the service insertion / chaining necessary to make things work. This again takes a functional Pluribus SDN product and takes it to the next level of usability and functionality.

Cisco Insieme

Cisco presented the ACI solution and, in addition to the beautifully prepared whiteboard diagrams that formed the basis for much of the discussion, I found that the focus of this discussion had shifted compared to previous sessions on ACI. This time it was not a presentation about the pure technical capabilities of ACI and the theoretical things that could be done with it, but instead focused on how it is actually used and configured, and how it can improve performance. If you want an ACI primer, this presentation as a whole is probably the best starting point I’ve seen so far.

Brocade

Brocade have always been an interesting vendor at NFD; they tend not to push products in our faces for two hours, but instead have typically spent at least 50% of their time promoting open source initiatives for SDN and network automation, demonstrating exceptional thought leadership in the SDN space, and – in the case of David Meyer – bamboozling us with whatever is on his mind at that time, and generally impressing us. But much of this can feel a little pie in the sky; it’s end game stuff, and when we get there, without question, Brocade is ready for us, and in spades. But how do you get people to the end game when there’s such a big jump from today’s networks to that final state? In keeping with the spirit of the week, we had an off-camera conversation with the venerable Michael Bushong for whom I have previously expressed my admiration. Michael moved to Brocade a few months back, and his role, as best I can understand it, it precisely to help Brocade fill that gap between today and tomorrow, and provide a logical path to get users engaged with SDN and comfortable with it. In some ways, this again means abstracting what’s going on and just providing things that are accessible and cost effective without needing a full DevOps team on board to make it happen. Again it’s about usability, not just the feature set on offer.

Network Management

This is not quite “SDN”, but if you can’t see it and manage it, you’re in trouble.

NetBeez

With echoes of another recent presentation, NetBeez presented their solution to multi-site network visibility, measuring user experience. The hardware is simple – it’s a Raspberry Pi in a case with a power supply – that can be deployed pretty easily on any remote site. Some USB WiFi ‘sticks’ are now also supported so the same tiny box can be used to measure and report on user app response times, available bandwidth, path changes (traceroutes, for example) and wireless networks (e.g. SSID listings and channel utilization – basic wireless survey information). The monitoring management interface is pretty clean and clear, though I’m not sure how it will be to use with a thousand end points. The key point put forward was to identify problems before users do. Who wouldn’t want that?

SolarWinds

SolarWinds presented both a broad overview of their products, and a focused look at some specific areas. The Wireless Heat Map was a nice feature, though currently limited to Cisco APs I believe. The overview was maybe the best part in some ways, because it’s the first time I’ve felt that SolarWinds has clearly dispelled the perception that they have a bunch of products that all present through the Orion interface, but are isolated from one another. They really tried to make clear that behind the scenes, data from the various program modules are shared and used to enhance analysis in each module where available. Neat stuff, and again many of their functions are aimed at identifying problems early so they can be addressed before it’s too late. The new capacity forecasting module is a good example of looking ahead.

My 10 Bits

The Networking Field Day team brought us a really interesting group of presenters, and it felt like we’re at a pivot point with the adoption of SDN solutions. In fact, people will likely be adopting solutions that they don’t need to think of as SDN, just as really good solutions for their needs. Ultimately, that’s how it should be. If “SDN” is a checkmark on your RFP, think again about what it is you really need. If SDN can deliver it, then that’s great.

SDN is just a tool with which to implement a feature; it’s not the feature itself.

 

Disclosures

The vendors listed above paid to present at Networking Field Day, and that money in turn paid for my transport, hotel and food/drink while I was at the event. I receive no payment to attend the event, and am under no obligation to tweet, blog or otherwise publicize the vendors or their products. Please read my full disclosure statement for more details.