ArubaOS 8.0.0 was released into the wild a couple weeks ago (at the time of this writing) with a ton of really nice changes, additions, and redesigns. As I was reading the release notes and loading it up in my home lab I was very happy with a few new additions like config auto-rollback (Woo hoo!), AppRF 2.0, centralized image management (Yipee!), new (beautiful) interface, and a whole new multi-tiered management architecture. All of these combined with the rest of the changes prove yet again why Aruba is a force to be reckoned with. As I continued reading through the release notes though, I was a bit astonished by a major feature that had been added… SDN. Specifically, OpenFlow.
Now, I’ve written about Wi-Fi and SDN before and it wasn’t good. I rambled a bit about how SDN could learn a lot from Wi-Fi since we’ve had a separate management, control, and data plane for a long time now. I lamented about the fact that interoperability is a bad word in the world of wireless networking. I finished with a simple “Why?” Why should we care about having wireless controllers running SDN when our controllers are connected directly to switches capable of taking over from there with all their flow-based wizardry? It made no sense to me why we should add that sort of complexity to already complex systems. Except, this time it’s different.
When you have a wireless controller, typically you are connected directly to switches that provide VLANs for your wireless users. That’s pretty much the status quo… that is unless you’re using Aruba controllers in your branches. Aruba’s “Cloud Services Controllers” offer the capability to put all of your branch office network services into one box; WAN, LAN, and WLAN all happily co-existing with all your connectivity and security policies unified. Add in some Aruba switches and you can synchronize and control those policies across all your devices, simplifying your network management to a single interface. That's really great when you run a ton of sites but it doesn't really answer my whole question of “Why?” Why should I care about SDN when I can already manage everything in one place?
Really, Why?
Okay, great. Now we’ve added an OpenFlow agent to the mix which extends our capabilities to manipulate traffic on a flow basis; inserting routes on the fly, giving switches the power to forward traffic based on ever-changing rules, and creating networks that adapt to the needs of your security or the needs of your users. That makes a bit more sense. Add in the ability to programmatically create rules based on unknowns that get forwarded from your data plane back to the controller for decisions to be made and policies created on the fly and the story gets even better. I concede, that sounds pretty good to me. The problem is that I’ve been out of the route/switch world long enough that I haven’t had time to tinker much with OpenFlow so I wouldn’t even know where to start… I wouldn’t even know which controller to use.
But Wait! There’s More!
Aruba didn’t just add an OpenFlow agent to their controllers, they turned them into full blown OpenFlow controllers (must be run on the mobility master). So now the device that manages your wired and wireless networks, your WAN and your LAN, your campus and your branches has the capability of controlling all of it based on the OpenFlow SDN standards. It is quite literally a turnkey SDN solution. And it’s based on open, industry accepted standards. The SDN controller feature has a northbound API for accessing the data via synchronous and asynchronous methods, a southbound interface for handling all data plane controls for your network devices, and platform services that manage host discovery, routing, and core functions.
Your network just became fully programmable, from end-to-end.
Aruba, I ♥ you.
#SDN