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…
But wait, there’s more… VSG was the first virtual service node that supported vPath, but in the last 18 months we’ve really rounded out all the key application networking and security services you could expect. Starting with vWAAS for WAN optimization, we then announced the ASA 1000V cloud firewall which is shipping this quarter (for more details on how the VSG and ASA 1000V firewalls complement each other, check here). At Cisco Live in San Diego, we demoed a virtual version of our ACE application controller for the first time. And more vPath-integrated virtual services are in the works. Imperva announced they were bringing their web application firewall to the Nexus 1000V environment, including vPath integration down the road.
Because of the mobility of virtual machines and virtual services between servers and even between data centers, and the rapid proliferation of east-west data center traffic (between VM’s), the challenge of diverting traffic to the right service nodes, in the right order, depending on the specific application policy, is complex. vPath is the most mature and advanced service routing technology doing this today, and it’s uniquely available in the Nexus 1000V. One of the most frequent questions I get asked when talking about vPath is if it will support physical appliances in addition to all of our virtual services, e.g. physical ASA firewalls and ACE load balancers. Cisco has had various service routing protocols for physical devices in the past, but consolidation around a single architecture for so many products has proven elusive. With the importance of virtual networking and the co-existence of virtual and physical data center services, it’s certainly an interesting strategy for us to pursue with vPath, although we’ve announced no such physical appliance integration to date.
The other frequent question we get is if vPath is going to be a standard, given its widespread adoption through the more than 6,000 Nexus 1000V customers to date, and its advanced status in the industry. Again, this is a very interesting question, but one we haven’t taken a definite position on yet. This multi-vendor market is still relatively nascent, and it’s probably premature to predict which virtual infrastructure vendors would be interested in a standard service routing infrastructure, what services would support it, what the benefits would be to the industry, or the benefits would be to Cisco.
Another question that we usually head off before being asked is, “Given all these vPath-enabled services being deployed now, where do they usually get hosted? On application servers alongside the virtual applications?” Well, what most of our customers do is deploy them on the Nexus 1010 virtual services appliance, rather than application servers. This actually gives more control to the networking teams to manage deployments and policies on these services, as well as offloading the mission-critical application servers. For more information on the Nexus 1010 role in deploying application services, click here and here.
Finally, as we circle back around to the recent acquisition news, the conclusion that I draw is that network virtualization infrastructure is strategically very important, but it may not be a company-maker itself like originally thought. And it could be highly competitive with some expensive reinventing of wheels. There will likely be a great deal of interoperability between various network virtualization “stacks”, which are increasingly built on open interfaces and protocols, like VXLAN. Value-add and differentiation (and the bulk of revenue) will be determined by higher level services as well as other applications and cloud orchestration suites built on top of the virtual infrastructure. Today those are represented by Cisco’s vPath-enabled virtual services described earlier, and applications like our Cisco Intelligent Automation for Cloud (CIAC), as well as future cloud orchestration apps built on the OpenStack API on the Nexus 1000V.