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]