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. Impervaannounced 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.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.