Hey, trying to start blogging more again. I’ve been busy the last couple months. I went to Cisco Live earlier this summer, moved into a new apartment, and am working towards my CCNP right now.

At Cisco Live, I found the walk in labs to be really helpful.  Having a chance to get hands on time with different technologies like LISP, FabricPath, and ONE was probably even more valuable than some of the sessions. Many of the SDN specific sessions I went to were quite “high level”, and lacked much in the way of concrete details.

The lab covering Cisco’s SDN platform (ONE) gave me a much better understanding of how Cisco’s SDN components fit together at the moment, though it’s also clear that this is still at work in progress. SDN (Software Defined Networking) is a big topic right now in the datacenter realm, and I thought it’d be valuable to share some of what I learned from the lab.

The major use case for ONE right now seems to be “topology independent forwarding.”  Meaning - routing traffic based on something other than the traditional best path characteristics (like most bandwidth, least latency, etc).  Maybe you want some traffic to always hit 1G links instead of 10G links for instance.  In our lab, we configured a matrix network.  This let us capture traffic on a given switchport, and forward that traffic through the SDN-enabled network to another device, irrespective of the normal L2/L3 forwarding tables on those intermediate devices.

There are several different components that interact in Cisco’s SDN platform:

Cisco SDN

 ONE Controller

Each of the network devices using ONE registers with a ONE controller.  The controller effectively aggregates the dynamic configuration of many devices onto one box - so that any external applications can use an API to talk just with the controller, they don’t have to communicate with each individual network device.

The controller is responsible for pushing flows out to the devices. The controller <–> agent communication uses the OpenFlow API (the southbound API). Flows can be manually configured on the controller, or dynamically generated by a custom application that communicates with the controller using Cisco’s northbound API.

The Open Daylight project is a Cisco sponsored open source project that is responsible for an open source version of Cisco’s ONE Controller. My understanding is this has the same core code base as Cisco’s ONE product, but it may lack some of the features.

Custom Applications

An external application can talk to the controller to dynamically tell it what flows to create. Technically you could use ONE without having a custom application, by manually defining the flows on the controller. But that would defeat the purpose of SDN - which is that traffic forwarding can be programmatically controlled using API’s to react to events. So, the custom application is really where you derive most of the value from. This is what ties your business or application logic in to the network infrastructure.

In the lab scenario, the Cisco’s custom application had a web UI that allowed you to select which port on which device we should capture traffic on, and which port on which other device the captured traffic should be forwarded to.

I would expect that Cisco and/or others will offer off-the-shelf applications for common use cases in the future. As far as I know, there aren’t many existing applications that integrate with ONE today. Depending on what you’re using ONE for, this functionality might be something that you use to integrate with an existing management or provisioning system.

 ONE Agent

The Cisco ONE Agent runs on the network device forwarding the traffic. It is actually an OVA file that runs as a VM on top of the software. It looks like they are using KVM.  If my memory serves, the devices we used in our lab were running NX-OS. Through NX-OS, we configured ports to be OpenFlow enabled. This allows the agent to apply configurations to them.

The controller pushes flows down to the agent using OpenFlow. The agent then configures the device itself to forward traffic based on the flows that it has learned. On the devices in our lab, this was accomplished using access lists.

Some traffic like LLDP is sent up to the ONE controller (it can use LLDP to discover devices).  For the actual data-plane traffic that we wanted to forward, the the access list uses “redirect” statements, which redirects matching traffic out of a specific egress interface.

I found this interested in two respects:

  • It’s separate from the normal L2 / L3 forwarding process (no MAC or routing table lookups)

  • The traffic isn’t handed off to a magic OpenFlow or SDN black box - the agent generates configurations that forward traffic using the existing features of the device.

Summary

My recommendation would be to look at SDN / ONE if you have a specific problem or traffic forwarding requirement that can’t be easily solved using traditional techniques. Right now, I think Cisco’s ONE is really only useful for niche applications. I don’t see it being particularly useful in typical mainstream enterprises. You can’t “replace” your existing enterprise campus or data center network with it.

I also think that Cisco has a much different vision of SDN than many of their smaller upstart competitors. They are likely much more interested in protecting their current business.  So their view of SDN seems to be more limited I think than what some other vendors' visions are.

Any thoughts on ONE or SDN in general?  Let me know, leave a comment!