Software Defined Networking has been bouncing around the marchitecture blogosphere for a few years now (even onto my own apparently), but what is it exactly? SDN enabled switches and routers promise to actually interact with the applications that are cruising along top of them, rather than blindly shuttling packets from point A to point B. This type of promised capability threatens to open up a lot of new options for your network. It could allow you to hand craft routes for particular classes of traffic without having to bring up the command line for dozens of routers. It could allow you to automatically prioritize and optimize video sessions as they are created, rather than having to rely on a blanket of “catch-all” rules. You could even create specific rules for individual users, tunneling all of their traffic (even intranetwork traffic) through a NGFW until their hosts are deemed healthy again.

So with all of this promise, why are we still hugging tight to our trusty CLI?

In my opinion, while it is an exciting technology, the term “software defined networking” has become a bit of a catch-all as more and more companies introduce their own version of SDN… and as a result, there can be some confusion around how it actually works underneath the hood. And to be frank, networking is a distributed system…. so it is critically important that each piece and part has to 1) be reliable and 2) play well with others. Despite the quirks, we at least know how STP is going to behave, we can work around the quirks, and we know that it’s generally going to be present in most environments. Completely reinventing tried and true protocols in favor of being at the bleeding edge of technology seems unnecessarily painful.

However, earlier this year I took a course around OpenFlow® and it opened my eyes a little bit to how SDN can complement the network, rather than replace it.

First, what is OpenFlow®? OpenFlow® is defined by the Open Networking Foundation ( as the first standard communications interface defined between the control and forwarding layers of an SDN architecture. In short, OpenFlow® can modify the forwarding plane on devices such as switches and routers remotely, creating a centralized and programmable control plane.

There are two common approaches to designing an Openflow® based software defined networks – pure Openflow® architecture and the hybrid model. In the pure Openflow® system, conventional routing logic and MAC address tables are replaced by “flow tables” that are built entirely through Openflow®. This gives the network administrator complete control over the network, but it requires a lot of experience with protocol behaviors and keen attention to detail – because spanning tree won’t be there to help out if a switching loop is introduced! This style of design doesn’t hold much appeal for me, as detailed above. The other option is the more commonly used Hybrid model, which overlays Openflow® on top of a conventional network. In the hybrid model, relevant network traffic is compared against Openflow® flow tables first, but if there isn’t a specific rule defined for the network flow it is passed down to the conventional network intelligence and it is handled as usual. The overlay model gives flexibility while still utilizing tried and true protocols.

HPE Aruba’s lineup of campus switching is a good example of the hybrid Openflow® architecture in action. Most of HPE Aruba’s campus switches are OpenFlow® ready out of the box. They have solid conventional network protocol support at the core that we all know and love/hate, but you have the option to introduce OpenFlow® enhancements with no additional feature licenses required. These switches have custom ASICs that were designed to provide full featured OpenFlow® support (take a look at the TCAM specs) and as a result they can perform flow table operations in hardware at almost line speed. This makes the network “programmable” – for example, you can specify that a specific traffic type from a specific host signature be mirrored to another location for analysis, modified as needed, and even be completely rerouted… while everyone else still moves along as usual.

So what pieces and parts make up the HPE Aruba SDN system? At the core is the SDN controller, which is installed on a VM in your environment. This controller establishes OpenFlow® tunnels to each managed switch so that it can orchestrate a centralized control plane. These OpenFlow® tunnels also allow the controller to insert or retrieve packets retrieve packets for analysis. Once the SDN controller is in place, networking apps can be loaded onto the controller to add additional features. Think of the HPE SDN controller like your smartphone – if you want added features on your phone (friend finding, picture filters, etc etc), you go to the app store, download an app, and you’re all set. HPE Aruba’s SDN system is similar. If you want to add features to your network you can go to the HPE SDN app store, select the functionality you want, install it on your controller, and then you are up and running.

HPE’s SDN App Store has 32 applications currently available for download, offering network enhancements ranging from active honeypot technology to software defined load balancing. Three premium applications are currently available from HPE, offering services like packet analysis from anywhere on the network, URL filtering through DNS interception at the access layer, and voice and video call prioritization for Skype for Business. In addition, the SDN controller can integrate with other software platforms thanks to its northbound RESTful APIs. Aruba’s ClearPass software can pass authenticated user information to the SDN controller via these APIs, which can then find and mirror network traffic specific to a named employee, regardless of where they’ve wandered on the network – making life much easier.

While SDN is still trying to make its “big break,” I think it promises to introduce significant changes in networking landscape… eventually. What are your thoughts?

To learn more about the Open Networking Foundation:

For a case study around South Washington County Schools that implemented HPE SDN:

For a case study around BAMA Company that implemented HPE SDN:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s