I consider myself to be a reasonably intelligent individual. Well, perhaps “reasonably” is a debatable term; just ask my friends. Or my wife. (Then again, don’t ask my wife.)
Reasonable or not, though, I’ve been trying to wrap my head around what all this “software defined” stuff is supposed to mean, and I have to confess it’s been a bit circular: it’s almost as if you have to already know the information you’re trying to learn.
So where are the Napkin Dialogues written for people like me? Is everyone a super-genius programmer-cum-networker-cum-programmer and I just missed the boat? People are throwing around these “Open” terms left and right (e.g., OpenStack, OpenFlow, OpenDaylight, etc.) as if it’s an “open” and shut case.
Well shut. The. Front. Door. I’m going to have to be on the receiving end of my own napkin then. For me, it’s been feeling like I’ve been dropped into the middle of a maze with the lights turned off.
[Screenshot of "Dark Maze" game by Zomg Games Studio]
Yeah, kinda like that.
If you already ‘get’ this stuff, feel free to help a poor storage networking guy along in his journey, because I already know this iceberg goes all the way down.
To someone who is familiar with tried-and-true Data Center designs, I’m just having a hard time getting my head wrapped around 1) getting from here to there, and 2) just where there is! Read More »
Tags: Cisco Nexus Switches, opendaylight, OpenFlow, OpenStack, OpFlex, software defined networks
As I was thinking about how best to advise you on how to “experiment” with SDN technologies, and more specifically why you should run a formal pilot to evaluate SDN technology options (a topic I covered in my previous blog), I was reminded of this “wipeout” picture I took last year at a “freeride” competition – the “Coe Cup“ -- at my local ski mountain, Glencoe Moutain Resort, here in the UK. Let me tell you why!
Why you may want to “pilot” new technology adoption!
Tags: ACI, Cisco onePK, cisco_services, network virtualization, OpenFlow, SDN, software defined network
Would SDN, by any other name, still smell as sweet?
Perhaps I’m in the minority that is still frustrated by this, but as a marketing person who is tasked with explaining technology and solutions to customers and prospects, I feel hamstrung by a lack of a widely agreed upon definition of what is and is not “SDN” still. This usually comes up in discussions about our new Application Centric Infrastructure (ACI), and how it compares to traditional SDN concepts, as well as alternative approaches, such as overlay networks advocated by VMware.
The topic came up again this with a NetworkWorld article in which the head of VMware’s network virtualization business is now saying, “SDN will never happen” (our rebuttal). Well, what is happening, if it’s not SDN? Or just because the technology has evolved, do we need to create a new term just because some early assumptions the industry made have changed? As we start out a new year, I thought it a good time to try and reframe the definition, and look at how the trends in SDN may be shaping up to extend the concept into new areas.
Why do customers need SDN?
By early 2012, there was so much hype and expectations around Software Defined Networking, focused on the ability to “program” the network, that real customer use cases and the killer SDN app was lost in the conversation. But what slowly emerged, that is driving all the investment, pilots and product designs is a much better way to manage the data center and cloud network, and to automate IT tasks so that the infrastructure could respond dynamically to rapidly changing business conditions and requirements. The “intelligence” to make all that happen is moving from the network devices and device management consoles, to centralized policy-management platforms, orchestration tools and cloud-managers.
What’s caused the biggest evolution in SDN is the realization that very few organizations really have the desire, skills and incentives to write a new class of applications to a published API to program the network. These users are outlying use cases compared to the vast majority of organizations just looking to automate IT tasks, accelerate application deployment, make their cloud networks more flexible, and better align their IT infrastructure with business requirements. The focus has shifted from SDN being an open API/controller platform, to a platform capable of hosting a myriad of orchestration and IT workflow automation solutions that drive customers to their end goal. To that end, ACI is meeting all those objectives, and in more advanced and innovative ways than earlier SDN approaches.
Read More »
Tags: ACI, Cisco ONE, Open Daylight, Open Network Environment, OpenFlow, OpenStack, SDN, software defined networking, XNC
We’ve been getting a lot of great questions about ACI since our launch as people try and better understand the value of an application-oriented approach. I got the following questions on my blog post about the Application Virtual Switch that probed on some of the thinking behind an application-aware architecture, and why now was the right time to release it (after all, John Chambers called it the most disruptive Cisco innovation in a decade!). Anyway, on to the Q&A:
I’d like to know more about the path that Cisco pursued to evolve towards an “application aware” architecture. This back-story (how Cisco arrived at this juncture) would be very helpful to industry analysts, customers and institutional investors. Here’s some of the key questions on my mind.
- What were the primary roadblocks that inhibited the adoption of this innovative approach in the past?
I would say that the Application Centric Infrastructure (ACI) was a combination of a Eureka! moment, that people just never thought of it before, and that it was also an insightful evolution from early SDN technology. So, it might be fair to say that SDN had to come along, and then we realized, here might be a better way to program the network (with an application-oriented model, rather than a network-centric model).
That might be another way of saying that the lack of SDN as a precursor to ACI was a roadblock. But I think of it as networks were just built on hardware that were optimized to pass packets and other very specific tasks. And the limitations of historical networking protocols and traditional network designs, coupled with very limited ways in which you could manage a network and tell it what to do, all served as roadblocks to implementing anything like ACI. So the roadblocks that had to be cleared included the ability to program switches through software interfaces, and to centrally manage the software applications or controllers to orchestrate the broader network, not an individual device. Those are some of the things SDN brought along.
Read More »
Tags: ACI, APIC, application centric infrastructure, Cisco ONE, nexus, onePK, OpenFlow, SDN, XNC Controller
Despite all the buzz about software-defined networking (SDN), many organizations don’t yet have a clear idea of how it will benefit them. In this blog, I’ll tackle the what and why of SDN, and explain the different approaches you can consider.
What: A Disruptive Approach to Network Control
For the last quarter century, network devices have performed two types of processing:
- The data plane looks at a routing table to decide where to forward packets. This processing takes place in dedicated hardware ASICs.
- The control plane takes care of everything else, such as spanning tree, AAA, exporting NetFlow statistics, SNMP, and more. The control plane is implemented in software, and you can think of it as the brains of the network element.
So, if your network includes 200, 2000, or 20,000 network devices, that means you’re managing 200, 2000, or 20,000 control planes and keeping all of them up to date. Read More »
Tags: Cisco ONE, Open Network Environment, OpenFlow, OpenStack, SDN, software defined network, virtual network overlay