Home > Cisco, Citrix, Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware > The Forthcoming Citrix/Xen/KVM Virtual Networking Stack…What Does This Mean to VMware/Cisco 1000v?

The Forthcoming Citrix/Xen/KVM Virtual Networking Stack…What Does This Mean to VMware/Cisco 1000v?

I was at Citrix Synergy/Virtualization Congress earlier this week and at the end of the day on Wednesday, Scott Lowe tweeted something interesting when he said:

In my mind, the biggest announcement that no one is talking about is virtual switching for XenServer. #CitrixSynergy

I had missed the announcements since I didn’t get to many of the sessions due to timing, so I sniffed around based on Scott’s hints and looked for some more meat.

I found that Chris Wolf covered the announcement nicely in his blog here but I wanted a little more detail, especially regarding approach, architecture and implementation.

Imagine my surprise when Alessandro Perilli and I sat down for a quick drink only to be joined by Simon Crosby and Ian Pratt.  Sometimes, membership has its privileges ;)

I asked Simon/Ian about the new virtual switch because I was very intrigued, and since I had direct access to the open source, it was good timing.

Now, not to be a spoil-sport, but there are details under FreiNDA that I cannot disclose, so I’ll instead riff off of Chris’ commentary wherein he outlined the need for more integrated and robust virtual networking capabilities within or adjunct to the virtualization platforms:

Cisco had to know that it was only a matter of time before competition for the Nexus 1000V started to emerge, and it appears that a virtual switch that competes with the Nexus 1000V will come right on the heels of the 1000V release. There’s no question that we’ve needed better virtual infrastructure switch management, and an overwhelming number of Burton Group clients are very interested in this technology. Client interest has generally been driven by two factors:

  • Fully managed virtual switches would allow the organization’s networking group to regain control of the network infrastructure. Most network administrators have never been thrilled with having server administrators manage virtual switches.
  • Managed virtual switches provide more granular insight into virtual network traffic and better integration with the organization’s existing network and security management tools

I don’t disagree with any of what Chris said, except that I do think that the word ‘compete’ is an interesting turn of phrase.

Just as the Cisco 1000v is a mostly proprietary (implementation of a) solution bound to VMware’s platform, the new Citrix/Xen/KVM virtual networking capabilities — while open sourced and free — are bound to Xen and KVM-based virtualization platforms, so it’s not really “competitive” because it’s not going to run in VMware environments. It is certainly a clear shot across the bow of VMware to address the 1000v, but there’s a tradeoff here as it comes to integration and functionality as well as the approach to what “networking” means in a virtualized construct.  More on that in a minute.

I’m going to take Chris’ next chunk out of order in order to describe the features we know about:

I’m expecting Citrix to offer more details of the open source Xen virtual switch in the near future, but in the mean time, here’s what I can tell you:

  • The virtual switch will be open source and initially compatible with both Xen- and KVM-based hypervisors
  • It will provide centralized network management
  • It will support advanced network management features such as Netflow, SPAN, RSPAN, and ERSPAN
  • It will initially be available as a plug-in to XenCenter
  • It will support security features such as ACLs and 802.1x

This all sounds like good stuff.  It brings the capabilities of virtual networking and how it’s managed to “proper” levels.  If you’re wondering how this is going to happen, you *cough* might want to take a look at OpenFlow…being able to enforce policies and do things similar to the 1000v with VMware’s vSphere, DVS and the up-coming VN-Link/VN-tag is the stuff I can’t talk about — even though it’s the most interesting.  Suffice it to say there are some very interesting opportunities here that do not require proprietary networking protocols that may or may not require uplifts or upgrades of routers/switches upstream.  ’nuff said. ;)

Now the next section is interesting, but in my opinion is a bit of reach in certain sections:

For awhile I’ve held the belief that the traditional network access layer was going to move to the virtual infrastructure. A large number of physical network and security appliance vendors believe that too, and are building or currently offering products that can be deployed directly to the virtual infrastructure. So for Cisco, the Nexus 1000V was important because it a) gave its clients functionality they desperately craved, but also b) protected existing revenue streams associated with network access layer devices. Throw in an open source managed virtual switch, and it could be problematic for Cisco’s continued dominance of the network market. Sure, Cisco’s competitors can’t go at Cisco individually, but by collectively rallying around an open source managed virtual switch, they have a chance. In my opinion, it won’t be long before the Xen virtual switch can be run via software on the hypervisor and will run on firmware on SR-IOV-enabled network interfaces or converged network adapters (CNAs).


This is clearly a great move by Citrix. An open source virtual switch will allow a number of hardware OEMs to ship a robust virtual switch on their products, while also giving them the opportunity to add value to both their hardware devices (e.g., network adapters) and software management suites. Furthermore, an open source virtual switch that is shared by a large vendor community will enable organizations to deploy this virtual switch technology while avoiding vendor lock-in.

Firstly, I totally agree that it’s fantastic that this capability is coming to Xen/KVM platforms.  It’s a roadmap item that has been missing and was, quite honestly, going to happen one way or another.

You can expect that Microsoft will also needto respond to this some point to allow for more integrated networking and security capabilities with Hyper-V.

However, let’s compare apples to apples here.

I think it’s interesting that Chris chose to toss in the “vendor lock-in” argument as it pertains to virtual networking and virtualization for the following reasons:

  • Most enterprise networking environments (from the routing & switching perspective) are usually provided by a single vendor.
  • Most enterprises choose a virtualization platform from a single vendor

If you take those two things, then for an environment that has VMware and Cisco, that “lock-in” is a deliberate choice, not foisted upon them.

If an enterprise chooses to invest based upon functionality NOT available elsewhere due to a tight partnership between technology companies, it’s sort of goofy to suggest lock-in.  We call this adoption of innovation.  When you’re a competitor who is threatened because don’t have the capability you call it lock-in. ;(

This virtual switch announcement does nothing to address “lock-in” for customers who choose to run VMware with a virtual networking stack other than VMware’s or Cisco’s…see what I mean.  it doesn’t matter if the customer has Juniper switches or not in this case…until you can integrate an open source virtual switch into VMware the same way Cisco did with the 1000v (which is not trivial,) then we are where we are.

Of course the 1000v was a strategic decision by Cisco to help re-claim the access layer that was disappering into the virtualized hosts and make Cisco more relevant in a virtualized environment.  It sets the stage, as I have mentioned, for the longer term advancements of the entire Nexus and NG datacenter switching/routing products including the VN-Link/VN-Tag — with some features being proprietary and requiring Cisco hardware and others not.

I just don’t buy the argument that an open virtual switch “… could be problematic for Cisco’s continued dominance of the network market.” when the longtime availablity of open source networking products (including routers like Vyatta) haven’t made much of a dent in the enterprise against Cisco.

Customers want “open enough” and solutions that are proven and time tested.  Even the 1000v is brand new.  We haven’t even finished letting the paint dry there yet!

Now, I will say that if IBM or HP want to stick their thumb in the pie and extend their networking reach into the host by integrating this new technology with their hardware network choices, it offers a good solution — so long as you don’t mind *cough* “lock-in” from the virtualization platform provider’s perspective (since VMware is clearly excluded — see how this is a silly argument?)

The final point about “security inspection” and comparing the ability to redirect flows at a kernel/network layer to a security VA/VM/appliance  is only one small part of what VMware’s VMsafe does:

Citrix needed an answer to the Nexus 1000V and the advanced security inspection offered by VMsafe, and there’s no doubt they are on the right track with this announcement.

Certainly, it’s the first step toward better visibility and does not require API modification of the security virtual appliances/machines like VMware’s solution in it’s full-blown implementation does, but this isn’t full-blown VM introspection, either.

Moreso, it’s a way of ensuring a more direct method of gaining better visibility and control over networking in a virtualized environment.  Remember that VMsafe also includes the ability to provide interception and inspection of virtualized memory, disk, CPU execution as well as networking.  There are, as I have mentioned Xen community projects to introduce VM introspection, however.

So yes, they’re on the right track indeed and will give people pause when evaluating which virtualization and network vendor to invest in should there be a greenfield capability to do so.  If we’re dealing with environments that already have Cisco and VMware in place, not so much.

/Hoff

  1. May 8th, 2009 at 10:50 | #1

    I'd be interested to hear how the Xen/KVM vSwitch handles Dynamic Arp Inspection, port-security, and many other features compared to the cSwitch (aka Nexus 1000v aka VSMVA). To think that it's even one-quarter as mature in feature set is a bit audacious, isn't it? That's like saying Vyatta competes with Cisco.

    Technology aside, Cisco provides the Enterprise wide-reaching instructional capital and free social capital around their products and services. Citrix will never be able to compete with this in the same way that VMware never will be able to do so. The Burton Group is smoking crack if they think Citrix/Xen/KVM fits outside of the SMB verticals or niche Enterprise placement.

  2. Kevin
    May 10th, 2009 at 04:40 | #2

    I'm wondering if it's really a good idea.

    My point is that it won't really help for network security.

    When you have physical wire, you can put a hardware firewall and you are sure that all the flow go through it.

    With third party vSwitch, it's up to the virtualization stack to send and receive packet to this vSwitch.

    For sure, you will be able to give back the network work to network admin and system work to system admins.

    But for security, I'm not sure it would help a lot (?)

    Maybe I'm wrong?

  3. May 11th, 2009 at 10:48 | #3

    Great post, Hoff. Let me start by saying (per Andre's comment) that I'm not on crack, though I've probably been accused of far worse things in my life. I've never held the position that an open source virtual switch would rule the enterprise, but this is a move Citrix had to make. Also, as analysts we often speculate of how competitors can shift the market. That's part of our job. 90%+ of our client base are large Cisco shops, and many of them are in the Nexus 1000V beta program. Citrix (and network vendors not named Cisco) need an answer to Nexus 1000V, and the open source virtual switch provides it. Regarding maturity, I never commented on it. Why should I when I haven't had a chance to touch the code? I will never recommend a product to a client that I don't use first hand, and the same can be said for virtual switches.

    That being said, I want to move away from Andre's comment and get back to Hoff's analysis of my post. With regards to lock-in, I completely agree. Lock-in is always about choice, and I could have made that more clear in my post. Citrix calls out VMFS as a form of lock-in, but when they package a solution that closely binds storage with a hardware OEM (e.g., NetApp, HP), XenServer customers are just locked in somewhere else.

    Regarding the VMsafe comparison, I also agree with your points. A better virtual switch is a good first step, but the real majority of the Citrix solution should come from the Xen Introspection project. Still, this means that security vendors are going to have to build and certify appliances for the Xen platforms that use introspection. In all likelihood, support for Xen Introspection will be in line behind support for a similar type of feature on Hyper-V (whenever that day comes). Support pecking order will continue to be VMware, Hyper-V, Xen, since software vendors place roadmap bets on market share numbers. Citrix and the Xen platforms would be better served by aligning with Microsoft on common security standards (allowing them to hitch a ride on the Hyper-V support bandwagon).

    The bottom line – Citrix and the Xen community are taking essential steps to build a platform to compete with VMware. Still, if you follow Burton Group's hypervisor evaluation criteria, VMware VI 3 and higher is the only hypervisor that makes the cut. We currently will not recommend any other hypervisor for production roles. We are seeing an increasing number of clients that want to do more with shared physical infrastructure (instead of doing security zoning by ESX cluster), so solutions that provide acceptable inspection and enforcement within the virtualization layer are beginning the transition from nice-to-haves to important features (and without a mature VMsafe product ecosystem, this still remains wishful thinking at this point). Thanks for weighing in on this topic. I always enjoy hearing your perspective. BTW – are you coming out to Catalyst this year? We have 2 1/2 days devoted to virtualization, and a full day on virtualization security topics.

  4. May 14th, 2009 at 02:49 | #4

    Hey Chris.

    I think the notion of ecosystem is the real tipping point here; none of the players are going to be successful without a good balance of integrated security capabilities AND a well-developed security ecosystem.

    NONE of them have that at the moment, including VMware. There are ISV's who are committed to VMware, but the VMsafe process has been slow, arduous and disruptive. Toss the vShield/Zones play in the mix and there are some pretty pissed off people at this point.

    Ultimately, virtual appliances are a messy answer to a difficult problem, so the 'revenge of the network' as it relates to how to integrate security back into virtualized environments will be a very interesting battle indeed.

    In regards to virtualization, I'm on, um, vacation ;) Unless someone's paying for me, the answer is unfortunately "no."

    Thanks for the insightful comments.

    I don't think you're on crack. ;()

    /Hoff

  5. May 14th, 2009 at 16:52 | #5

    Totally agree on the ecosystem part. I had long talks about security with three of the clients I met with in LA this week. In every case, the consensus was that VMsafe was a good architecture, but we'll need to get past the 1.0 revs of the ecosystem products before it'll be seriously considered. So we remain a good year away before virtual security appliances will begin to creep into the enterprise. Sure there are a few good ones today, but traffic inspection and policy enforcement within the virtual infrastructure is going to take awhile to mature. Zoning at the physical cluster level is going to remain for quite some time, IMO.

  6. May 16th, 2009 at 00:32 | #6

    I find it most interesting that KVM is being invited to the party, but not Hyper-V. This is most contrary to the "XenServer as placeholder" role that Citrix appears to have taken with regards to the Virtualization market (if Essentials are any indication, and I think they are.)

  7. July 15th, 2009 at 19:48 | #7

    I thought I knew alot about KVM switches and then I read this and I feel like a rookie. I didn't realize KVM switching got so in depth.

  8. February 23rd, 2010 at 06:45 | #8

    What it is interesting is that the open source community appears to have gotten some S-Flow support started on the openswitch platform:

    http://openvswitch.org/pipermail/announce_openvsw

    Do you have any sense for how quickly this will be available? Is anyone at MSFT or its partners working on something similar for a Hyper-V "managed vSwitch"?

    It seems to me that the move to extended virtual switches is largely about management and data export to traditional network tools, not forwarding technology. This sort of capability will be needed to match the 1000V value proposition.

  1. May 11th, 2009 at 07:19 | #1
  2. May 26th, 2009 at 19:15 | #2
  3. June 9th, 2009 at 07:53 | #3
  4. January 31st, 2010 at 17:19 | #4
  5. May 25th, 2010 at 00:05 | #5
  6. August 26th, 2010 at 07:08 | #6