Cisco Blogs

Security in a Virtual World: Cisco Virtual Security Gateway for Nexus 1000V

September 1, 2010 - 11 Comments


At VMworld yesterday, Ed Bugnion introduced our Cisco Virtual Security Gateway (VSG) for Nexus 1000V, which led to an avalanche of questions.  There is only so much you can do 140 characters at a time, so I thought this might work a bit better.  And, for those of you who weren’t at VMworld, here are answers to questions you didn’t even know you had.

So, a bit of context first…


The Virtual Security Gateway is the first instantiation of a broader data center services strategy you will be hearing about in the next few weeks.  The focus of this effort is to give customers a better way to deliver security and L4-7 services in a contemporary data center where virtualization and cloud computing are a fact of life.

The strategy as a whole is designed to allow customers to consistently deliver service across both physical and virtual infrastructure. One element of this approach is the concept of a virtual service node (VSN), which is essentially a virtual appliance designed to deliver services in a virtual form factor —the Virtual Services Gateway is an example of a VSN.

The VSG allows us to apply and manage firewall policy at a per-VM level.  Working as an extension of the Nexus 1000V, the VSG builds on the benefits of the Nexus 1000V:

  • VM-level granularity – apply, manage, audit policy at the VM context level
  • vMotion support – policy stays intact across manual and automated vMotion events
  • Non-disruptive operations – server admins apply policy to VMs via vCenter—ownership of security policy stays with security team

The VSG uses a zone metaphor for creating security policy. VM membership in a particular zone is determined by associating a virtual machine, network or custom attribute with a VM profile, which means that enforcement of policy is decoupled from where a VM happens to be sitting.  This is an important point—zone membership (and by extension policy enforcement) is now independent of physical server location, physical port or VLAN membership. Once a VM is placed in a zone, we use security rules to control what other zones it can talk to. 

The strategy for designing zones is at the discretion of the customer.  You could define zones for different customers in a service provider environment, different departments in the same company, or different types of applications with different policy requirements are all possible examples.

What makes the VSG really interesting is an innovation we call Cisco vPath that provides intelligent packet steering.  What is that exactly?  Well, amongst the goals of our services strategy are greater deployment flexibility, simpler designs, and better efficiency.  One way to accomplish that is to decouple policy lookup from policy enforcement.  With the VSN model, we use a centralized VSN to do the initial determination if two VMs should be talking then push enforcement of the policy for the balance of the flow back down to the Nexus 1000V responsible for that VM.

This approach gives you a lot of deployment flexibility.  The VSG VM can be placed on the same server as production VMs or placed on a separate, dedicated server.  In either scenario, a single VSN VM can support multiple servers thus reducing the amount infrastructure that must be purchased and managed.  The VSGs can also be deployed in an active/standby configuration to provide higher availability.

vPath also provides performance advantages, since only the initial packets of a flow need to go to the VSG, there is less packet steering going on.  Subsequent policy enforcement is done by the local Nexus 1000V VEM in kernel mode, so you get better performance overall.

Finally, its worth mentioning the operational model.  As noted above, we extended the model we introduced with the original Nexus 1000V.  The security admin maintains control of the security policy, but we still make it one-click easy for server admins to access and apply security policy via vCenter.  This way, we continue to break down silos and give everyone better visibility while still maintaining control and accountability.

On the topic of managablity, Cisco and VMWare are partnering to integrate VSG into VMWare vCloud Director, leveraging the points of integration that vShield Manager provides.

So, that is the high level overview of the VSG.  I’ll try and get a screencast pulled together next week to give you an idea of what it looks like in real life.  In the interim, post your questions as comments and we’ll get them answered.

[edited 8/1 – clarify integration with vShield and vCloud Director]

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Omar will vPath and Virtual Service Domains be available on more than the virtual Nexus switches? We are considering UCS but I want to know if all the flow based policy features will also be available in physical switches. All if I get an answer from my account rep I will let you know.

  2. OK.. Its been 6+ months.. Where it is?

  3. I heard through the grapevine that Cisco's ASA team wants to launch a vASA. Even possibly using vPath to steer traffic to an external ASA.

    • Bob I think to steer traffic to an external ASA, or a virtual one for that matter, you would need to use Virtual Service Domains. From what I understand vPath is stateless and only the first frame/packet in the flow goes to the VSG/SVM. See

  4. I'd like to know how VM to VM traffic in the same VLAN is handled. As this will generally be handled at layer 2 (ARP) rather than layer 3 (IP), therefore is it possible to push this traffic to the VSG? Or will this still require the Private VLANs functionality to segregate VM's in the same VLAN?

    • Brett from the picture of VLANs and Zones I am thinking intra-vlan traffic can be filtered.

  5. Omar covers this quite well again on TechWiseTV today at 10 AM PST - Robb

  6. Looks like a quite good product. Just one question... Does it run on the Nexus 1010 appliance as well like the NAM virtual appliance does?

  7. Are the Virtual Service Nodes (VSN) analogous to Service Virtual Machines (SVN), referenced here: ? And similarly are the zones mentioned in the article Virtual Security Domains (VSD)?

    • VSN's and SVN's are definitely not the same. SVN's (eg. VMWare Vshield App) are state-full and are required on each host. VSN's (eg VSG) are more analogous to OpenFlow's - - openflow controller. Also one can serve multiple hosts and the flow based firewall is stateless. The two technologies appear to be complementary.

  8. This looks promising indeed. Any information on expected launch date on this product? Also anything regarding the GUI ?