The lack of programmability in existing networking hardware is certainly a problem, but VMware’s acquisition of Nicira does not mean that Cisco and its ilk will be marginalized… It does mean the role and management of the physical network is changing, and I think Cisco is further ahead than most of its competitors in creating a vision for the next phase of networking.
I couldn’t agree more. Since Cisco live! when we announced our Cisco ONE strategy for network programmability as well as the advances in our Nexus 1000V portfolio for virtual network overlays, I have been posting on many of the same points.
My take here was that the VMware-Nicira acquisition did not portend a strategic break with Cisco, and while there are some obvious overlaps in our product lines, there are still a number of areas of collaboration, cooperation and interoperability. The virtual network infrastructure is just one piece of a larger software stack and the differentiation will likely be decided in the orchestration, management and applications built on top of the newly programmable infrastructures sometime down the road. Read More »
For me, even though I am mostly a hardware geek, one of the coolest parts of the Cisco ONE launch at CiscoLive was the introduction of onePK. We see onePK as an core enabling technology that will have some cool stuff down the road.
So, one of the more common questions I get is about the relationship between onePK and other technologies related to network programmability such as OpenFlow (OF). Many folks mistakenly view this as an either/or choice. To be honest, when I first heard about onePK, I thought it was OpenFlow on steroids too; however, I had some fine folks from NOSTG educate me on the difference between the two. They are, in fact, complementary and for many customer scenarios, we expect them to be used in concert. Take a look at the pic below, which shows how these technologies map against the multi-layer model we introduced with Cisco ONE:
As you can see, onePK gives developers comprehensive, granular programmatic access to Cisco infrastructure through a broad set of APIs. One the other hand, protocols such as OpenFlow concern themselves with communications and control amongst the different layers—in OpenFlow’s case, between the control plane and the forwarding plane. Some folks have referred to onePK as a “northbound” interface and protocols such as OpenFlow as “southbound” interfaces. While that might be helpful to understand the difference between the two technologies, I don’t think that this is a strictly accurate description. For one thing, developers can use onePK to directly interact with the hardware. Second, our support for other protocols such as OpenFlow is delivered through agents that are built using onePK.
That last part, about the agent support is actually pretty cool. We can create agents to provide support for whatever new protocols come down the pike by building them upon onePK. This allows flexibility and future-proofing while still maintaining a common underlying infrastructure for consistency and coherency.
For instance, we are delivering our experimental OF support by building it atop the onePK infrastructure. For customers this is a key point, they are not locked into a single approach—they can concurrently use native onePK access, protocol-based access, or traditional access (aka run in hybrid mode) as their needs dictate. Because we are building agents atop onePK, you don’t have to forgo any of the sophistication of the underlying infrastructure. For example, with the forthcoming agent for the ASR9K, we expect to have industry leading performance because of the level of integration between the OF agents and the underlying hardware made possible by onePK.
In closing, you can see how extensible our programmatic support is with the ability to use onePK natively or to support technologies and protocols as they are developed and released. This gives customers a remarkable level of flexibility, extensibility and risk mitigation.
Is networking really cool again? Obviously, all of us at Cisco think so. Judging by the hype around a few networking start-ups, and moves by major IT vendors to add networking capabilities, we’re not alone.
The activity and innovation in our category validates something we’ve always believed: the intelligent network is the most strategic asset for our customers, partners, and even our competitors.
And we expect to see new competitors. As we often say at Cisco, if you don’t have good competitors, then you’re probably in the wrong markets.
Now the question on many people’s minds is whether the current transition in the market – a transition defined by terms such as Software Defined Networking and network virtualization -- represents a threat or an opportunity for Cisco. As you might expect, Cisco has a strong point of view on this.
First, SDN, network virtualization and overlay networks (choose your favorite descriptor) are not going to commoditize the underlying networking infrastructure. These architectures actually place more demands on the core infrastructure to enable network virtualization securely, with high performance, at scale.
Why? Because customers expect their core infrastructure to be seamlessly integrated with servers and fabric interconnects. They want a common management framework across all switches (physical and virtual), and they want the ability to support heterogeneous server and hypervisor environments. Our experience is that they expect their networking vendor to fulfill those needs.
Wow, there’s been a lot of news in the SDN and virtual networking space in the last week or so! VMware acquiring Nicira, and Oracle acquiring Xsigo are testimony to how important virtual overlay networks and virtual switching infrastructure has become for data center vendors, and how integral they are to each company’s strategy. Speaking of our own Nexus 1000V-based virtual networks, last week I provided an overview and some new resources on Virtual Extensible LANs (VXLAN) for Nexus 1000V virtual switches. That turned out to be quite a popular post, so I’m following up this week on another fundamental component of Nexus 1000V-based virtual networks, vPath, the secret sauce that allows us to deploy virtual network services in the data center.
What is vPath? Well, if VXLANs can set up secure tunnels over a shared, multi-tenant virtual network, vPath is a feature of the Nexus 1000V virtual switch that can redirect traffic to virtual application services before the switch sends the packets down into the virtual machine. Very important stuff, but how does it do that? I find that my blog posts are more popular the less I type, and the more I embed cool TechWiseTV videos that illustrate the concept, so I’m dusting off this classic from the TWTV team on just how vPath does that with our Virtual Security Gateway (VSG). Take it away Robb…
At Cisco live last month I spent several days talking to a lot of customers about all the new enhancements to our Nexus 1000V portfolio, especially the programmable virtual network overlays that are part of the Cisco ONE framework for SDN/network programmability. While the Nexus 1000V-based virtual networks are really gaining traction (6,000+ Nexus 1000V virtual switch customers to date), I still found a lot of folks weren’t all that familiar with the concept of VXLAN, and why they are so important to building scalable cloud networks and multi-tenant data centers.
Well, not to fear, VXLAN MAN is here! Well, not really, but we have just released a great new fundamentals video on VXLAN from the creative geniuses at Techwise TV (Thanks to @JimmyRay_Purser and @robbboyd!). We’ve gotten great reviews on this so far, and I know the guys really had a fun time in creating this one.
The lack of programmability in existing networking hardware is certainly a problem, but VMware’s acquisition of Nicira does not mean that Cisco and its ilk will be marginalized… It does mean the role and management of the physical network is changing, and I think Cisco is further ahead than most of its competitors in creating a vision for the next phase of networking.
