VSG: Vive la difference! A Tutorial for HP

July 27, 2011 - 13 Comments

One of the things I admire about Cisco marketing, and I think generates a lot of respect for us from our customers, is how we approach competitive marketing. Most importantly, we hardly ever do it. Sure, we arm our sales teams with specific comparison data, but it’s rare we feel the need to compare ourselves publically or to bash competitors. When you bash a competitor, it really only serves to give them credibility, and highlights that they must be doing something important to occupy your mindshare, or that of your customer’s.  Occasionally though, we are faced with not only having to take the gloves off a little more, but responding to the inevitable FUD that gets thrown our way.

This brings us to a blog post written by HP about Cisco’s Virtual Security Gateway (VSG), which unfortunately contains a number of inaccuracies and misrepresentations of our product that we have to clear up.

Let’s start with this example:

Cisco has a product called the Virtual Security Gateway (VSG) for the Nexus 1000V Series. It is a virtual firewall that lets you enforce policy and segmentation virtual environments. All associated security profiles are configured to include trust-zone definitions and access control lists (ACLs) or rules. They also support VM mobility when properly configured. If there’s one thing the company is good at, it is those good-old ACLs developed back in the early 90s!

The strength of VSG’s firewall capabilities is its awareness of the virtual machine environment, and specifically the ability to write firewall rules based on the attributes of the virtual machine, attributes such as the NAME of the VM. This gives tremendous power to establish policies in virtual environments, such as logically isolating tenants running on the same machine, or separating VMs based on operating system or application type in virtual desktop environments, a use case I wrote about earlier. To imply VSG is enforcing good-old ACL’s from the 90’s is disingenuous at best.

The other advantage that VSG offers is VLAN independence. Security policies are mobile and migrate along with the virtual machine to other servers and other data centers. HP relies on VLAN tags to direct traffic to their physical IPS appliance, not a virtual appliance. Any physical appliance introduces scale and mobility limits that a purely virtual solution can overcome.

There are a number of other advantages that VSG offers through our virtual service routing technology, vPath, in the Nexus 1000V, such as performance and data path optimization through policy caching directly in the switch, topology-agnostic deployments, and improved CPU capacity planning across application workloads and firewall processing. See the resources below for more details on all of these.

What’s most glaring is that the company offers a virtual firewall that works with VMware, but there’s no integration with VMware’s vShield. vShield is part of VMware’s vSphere and offers virtual firewall capabilities similarly to VSG. I thought the two companies were partners?

I’m not sure why HP is compelled to comment on the nature of our relationship with VMware, which remains as strong as ever. Our distributed virtual switch and distributed virtual firewall provide significant value to the virtualization infrastructure of both the network and our UCS servers. As a result, with our virtual network infrastructure we don’t need to rely on any component of vShield.

I’m confused as to how this solution is marketed to provide the same security as your physical data center. I’m pretty sure that most enterprise data centers, whether physical or virtual, have at minimum intrusion prevention systems (IPS). In fact, I thought most IT departments were already looking at a range of security measures, including:

  • web application protections
  • application identification and control, and even
  • reputation services

Many of these technologies are being deployed because of mandatory compliance initiatives, like PCI. Wouldn’t I be taking a step backwards if I moved my critical assets into a VM running just a firewall?

Confusion is natural when one conveniently looks at bits and pieces and not the whole story. Here HP seems to imply that our virtual firewall is the only security device allowed in the data center.  Customers want to surgically address the blind spot created in the virtualized environment due to VM-to-VM traffic with a virtual firewall solution.  In addition, customers continue to adhere to security best practice of deploying physical firewalls/IPS/VPN/NAT at the Internet edge and in data center core using the ASA 5585-X and ASA service module in the Catalyst 6500 switches.  For applications like desktop virtualization, PCI compliance, multi-tenancy, et al. there is a much greater demand for firewall capabilities and policy enforcement at the VM-level. To imply that we can’t do everything in one specific virtual product, VSG, is very misleading.

And finally, there’s this unsubstantiated quote:

I think they’d rather sell more UCS. Oh wait, they aren’t really doing much of that either. But I digress…

Actually, we are selling a lot of them. UCS just became the #3 blade server vendor in only 2 years, taking significant market share from both larger competitors. We have 5400+ UCS customers worldwide as of last quarter, and are approaching 20% market share in the US. In April, 2010, HP famously predicted, “A year from now… UCS is dead”. See other famously bad predictions here.

The bottom line is that VSG is a very strong product for Cisco, and we are rapidly gaining market share and momentum. Customers understand that even if HP doesn’t. I always find you have to be very careful when you talk about someone else’s products, because it can sink your credibility fairly quickly.

For a more accurate and in-depth review of VSG and Nexus 1000V solutions, we invite people to explore our in-depth webinars and cloudlab tutorials available here: www.cisco.com/go/1000vcommunity [Note: cloudlab requires Cisco employee sponsorship to access.]

Also related: UNS Spotlight on VM-ready Security Solutions with VSG

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. Cisco’s announcement of ASA 1000v today — http://www.cisco.com/en/US/partner/prod/collateral/vpndevc/ps6032/ps6094/ps12233/qa_c67-688050.html

    Could you comment on long-term functional/feature differences between the VSG and ASA 1000v product offerings?


    • First of all, VSG is just a virtual firewall, and ASA 1000V is a virtual firewall plus VPN, attack prevention, NAT, DHCP, etc. But the advantage that VSG has is that it has better visibility to virtual machine (VM) attributes than an ASA firewall. So the firewall rules that you can write, and the policies that you can enforce with VSG may be better suited to your security requirements. For example, I can separate VM’s into trust zones with VSG based on the name of the VM, so I can logically isolate them based on application, virtual desktop cluster, operating system, etc. These usage scenarios all generally apply to isolating VM’s from each other inside the data center, rather than protecting clients from hitting a particular tenant in the data center. So we say that VSG is better for creating trust zones inside the tenant, and is for VM-VM (or east-west) traffic. ASA 1000V generally relies on more traditional firewall rules based on IP and Mac addresses, rather than VM attributes, so we position it as a firewall between a cloud tenant and other tenants or the outside world. What we call a tenant-edge firewall. At the tenant edge, all these other security services, like VPN and IPS make more sense as well than between VM’s. Hope that helps!

  2. Thanks for sharing.

    “with our virtual network infrastructure we don’t need to rely on any component of vShield”.
    vShield 5 has 3 components: edge, app, EP.

    A technical blog explaining how it does not need (or does need) would be much appreciated.

    Thanks from Singapore

  3. There’s a major shift approach with how security and app-aware services are wrapped around VM’s. In the past, we used VLAN tags to force traffic through virtual/physical appliances. In the future, hypervisors may handle the redirection.

    Cisco’s view is N1Kv and its VPATH redirection. VPATH supports VSG and WAAS today, and presumably will support Cisco IPS and SLB in the future. VPATH is Cisco-proprietary and no API is available for others to develop to.

    The problem is that VMware already has a built-in hypervisor redirection API called DVFilter (part of VMSafe) that does the exact same thing. Naturally, this is the what everyone else is developing for.

    As for this little spat between HP’s Sanjay Raja and Cisco’s Gary Kinghorn, Sanjay is definitely a bit fast-and-loose with the facts, but Gary’s rebuttal has several debatable quotes:

    “HP relies on VLAN tags to direct traffic to their physical IPS appliance, not a virtual appliance.”

    Cisco has dozens of products that require VLAN tags for traffic direction. That’s nothing to critize. And just as Cisco has now embraced hypervisor redirection with VPATH, the latest Tippingpoint S6100N and Juniper vGW/Altor products use DVFilter for the same effect.

    “Any physical appliance introduces scale and mobility limits that a purely virtual solution can overcome.”

    This implies that an all-virtual solution magically avoids issues of CPU, RAM, and I/O. That’s obviously bunk. The value of an all-virtual solution is with its rapid deployment and reduced physical footprint. Operationally, all-virtual solution is often more trouble when pushed to its capabilities since bottlenecks emerge in places you’re not expecting — hypervisor context switches or the variable CPU consumption of the VEM or DVFilter agent (the thing that does the redirection).

    “To imply VSG is enforcing good-old ACL’s from the 90’s is disingenuous at best.”

    This is sadly where I have to agree most with HP. Today’s VSG may have a nice policy interface, but its core security is not much better than layer-4 packet filtering with basic stateful inspection and ALG’s for FTP, TFTP, and RSH. Granted it’s not a NAT-enabled perimeter firewall, so many ALG’s aren’t needed. But did someone forget that there might be just a wee bit of MS-RPC/EPM and Sun-RPC/NFS in the target environment?

    I think the real problem is Cisco throwing everything at N1Kv/VPATH while the rest of the industry embraces DVFilter. Cisco’s strategy might work if they had a must-have product on day 1, but VSG doesn’t seem to fit the bill.

    • “…the real problem is Cisco throwing everything at N1Kv/VPATH while the rest of the industry embraces DVFilter”.

      Good for the rest of the industry if they embrace DVFilter, but what customer, either enterprise or service provider, really cares? They don’t care what low level mechanism or API is used. They are more concerned about the functionality of the solution, and many would prefer a solution that is not locked to a single vendor’s underlying API. And I would argue that any day 1 functionality you could quibble with is irrelevant to the longer term strategic benefits that we can offer customers moving forward by building on Nexus 1000V. More details later this month at vmworld… Stay tuned.

  4. Wow…childish and pathetic…that’s a little over the top.

  5. Chris,
    You’re kidding, right? Hopefully I’m just being a little sensitive because I’m fighting a lot of HP vs UCS battles right now.

    HP had 126B in annual revenue to Cisco’s 40B. Just to clarify, HP is bigger…right? I frame that as a question because like many other people, you’re obviously drinking too much of the Cisco Kool-Aid and perhaps you have a different view.

    • Thanks for the revenue perspective. I can imagine the UCS battles are wearing you down, but I got called childish and pathetic. There’s no room to be sensitive in this industry! 🙂

  6. Gary, I could’t agree with you more on both your initial comment and your reply. Your tone was spot on. Bashing competitor’s products does no service to anyone. You did not attack HP, you simply clarified their misrepresentation of the facts around a great Cisco product.

    It is valid and valuable to refute dis-information and to deliver accurate apples to apples comparisons. I am proud that this is a standard to which Cisco adheres.
    Adhering to full transparency for comments, I am a Cisco employee.

  7. Chris, I appreciate the comment, but Cisco has to clarify factual misrepresentations of our products that appear in public forums from both “small fish like HP” as well as larger companies. That IS letting our products do the talking. Had we responded back with the same tone, I might have agreed with you more.

  8. You guys might wanna stick to the mantra you speak of in the opening paragraph. It’s one thing for a small fish like HP to bash its competitors, but its a whole other thing for a company as big as Cisco to do it. Let your products do the talking. Articles like this smell of desperation and fear. Coming from the market leader, it’s a little childish and more than a little pathetic.

    • HP is not a ‘small fish’. HPQ Market Cap = $75B, CSCO Market Cap = $88B. I would say they are peers.

      • Market cap…really?
        I guess the comment above didn’t define his measurement of “small fish”
        If we knew how he defined “small fish” we could make valid arguments.