HP versus Cisco: to tag VM’s or not to tag VM’s
Tag, you're it!
Recently there has been some eloquent flaming back and forth between Cisco and HP over the VN-Tag, of course I have an opinion and figured I would vocalize it. Scott Lowe has a good piece on this as well, focused more broadly on the implications to the unified computing system.
First off, I do not think there is a lot of innovation that comes directly out of the standards bodies. However, i firmly believe that in today's mature networking market in order for a technology to get a decent traction and following it must at least be inserted into the standards process and be on a trajectory towards being multi-vendor and open/interoperable.
Secondly, I believe that innovation should be rewarded. "To the innovator go the spoils" I say. Innovation is risky, there should be a bit of light at the end of the tunnel. I am not-so-subtly reminded of a conversation with about 20 customers I led a few months back. I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard- the gentleman from a large manufacturing company interrupted him and said, "I don't care what standard they support, as long as they solve business problems for me I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs."
Lastly, and somewhat controversially, I think there are enough tagging formats out there already, and worse: most of them have no interoperability plan or architectural tie-in with each other.
Let's look at VN-Tag with these three lenses now....
1) VN-Tag was jointly developed by Cisco and VMWare to address a problem their customers were having: they could not bind a policy to a VM and have that policy move with the VM in a DRS or VMotion environment. They also felt that traffic could go from one VM to another, bypassing any network policy for governance or regulatory compliance and thus have a tail-end/hop-off type of attack possibility for VMs on the same physical host.
2) It was submitted to the IEEE, but is not a standard yet, thus to be binary it is 'proprietary' although it seems the companies are not holding onto the IP specifically, they just want to execute on a time-to-market advantage. (this is no worse and the ongoing CEE vs. DCE debate (note: there both are proprietary... DCB is the IEEE standard))
3) It is 'yet another' tagging format. If you trust that MAC addresses will not change dynamically the same problem-set could have been solved by binding network policy to the MAC address of a host.
Was VN-Tag necessary? maybe...maybe not. Personally, I think many of the same problems could have been solved if the MAC address was used to instantiate policy. There is a legitimate concern that the MAC address could be spoofed, but then again so could a multi-byte tag structure too unless it has signing/authentication/etc.
Is it proprietary? Yes. Although all indications are Cisco and VMWare are working to shape an industry 'de jure' standard and are trying to gain a time to market advantage over merchant silicon based players. (I would argue that innovation should be rewarded so a time to market advantage in silicon is not out of the question and probably shouldn't be demonized).
Is it well implemented? Here is the rub of the whole thing. Implemented broadly this is a promising capability for a network to have. VM's are, after all, the building block of many leading edge new data centers. However, VN-Tagging does not seem to be broadly embraced across the portfolio of products in the data center. At least I can see no indications of shipping products or announcements of how this capability is going to be brought into the security products, application networking products, routing products, rest of the Nexus line, etc. Broadly implemented in a coordinated fashion- this would be a powerful capability. Sporadically implemented in one or two products will lead to little impact.
This will probably get flamed a bit, so am finding the nearest asbestos store...dg
Additional comments powered by BackType
interaction
- Carrie on Interop 2010
- Chalon on Interop 2010
- nohype on Interop 2010
- SFoskett on Interop 2010
- Danny on Validating Some Power/Cooling Cost Assertions
texthibition
- @cxi let me know how Chicago goes, I have some new VM stuff would love to present up there if they have a good group! in reply to cxi 1 day ago
- pulling together another cool product/sw launch - been working on this one for last year. Excited... 6 days ago
- @vTrooper @vTrooper I need a few linecards in there too :) in reply to vTrooper 1 week ago
- @theosison Yes, Arista Networks :) in reply to theosison 1 week ago
- RT @yogeshmalik: SUN, CISCO and GOOGLE guys company Arista Networks show chassis switch, running 10,000 servers for $140k http://ht.ly/2em1s 1 week ago
- More updates...
Posting tweet...
coffee fund
default gateway
- A bet on BBCs and VM Mobility July 26, 2010
- Innovations - something I love in networking... July 21, 2010
- Why Data Centers Must Fundamentally Change -- Part 2.2 May 18, 2010
- Why Data Centers Must Fundamentally Change -- Part 2.1 May 17, 2010
- Why Data Center Networks Must Fundamentally Change May 10, 2010
July 28th, 2009 - 08:30
Phl Calvin, via FriendFeed, asked me- “What is HP’s alternative? Is it to use the MAC Address?”
Good question Phil – can anyone comment?
July 28th, 2009 - 10:43
Using the MAC address instead of the tag does not help for two reasons:
1. What about traffic that is local between two VM’s on the same server? How do you get your policies applied uniformly to this traffic? The answer is that the vswitch would do it, which is great for Nexus 1000V but not so great if you are using a standard vswitch that does not have the security feature you need — in that case, you really want all traffic routed through your top-of-rack switch.
2. What about broadcast and multicast traffic coming into the vswitch from top-of-rack? If your vswitch applies policies based on the egress virtual port, you are okay, but if you are attempting to apply policies in top-of-rack, you are stuck, because the top-of-rack switch can’t treat the packet differently on a per-destination-host basis when the vswitch is simply going to flood the packet to several destination virtual machines.
In summary, doing everything based on MAC address is (in general) the same as doing everything based on port, which is the status quo today. Both MAC-address-based policies and per-port policies work great when the vswitch has the features, and they are both inadequate when you want the top-of-rack switch to do the heavy lifting.
In reality, the primary purpose of VN-TAG-like tagging schemes is not about making policies follow VM’s. You don’t need VN-TAG for that — you just need a vswitch that can enforce the policies. The purpose of VN-TAG is fundamentally to enable an aggregation switch to perform access-layer functions. To me, this appears to be a significant and unnecessary complication in LAN architecture, when the obvious answer is to perform access-layer functions in access-layer switches. It is not the sort of innovation that should be rewarded in my view, and I am hopeful that the IEEE sees things the same way, namely: we should create standards to solve customer problems, not to protect the business models of large network equipment vendors.
July 28th, 2009 - 11:00
Ken- am with you on the ‘put the right function in the right place’ but if the access-layer device is virtual and doesn’t have the capability is the answer to a) work with the virtual switch vendor to improve theirs b) build your own virtual switch or c) find a creative way working within the existing standards to carry policy between a non-capable access layer and the aggregation switch?
I see your point on the rigid segmentation model falling apart in multicast/broadcast environments too depending on how the upstream devices handles multicast replication.
July 28th, 2009 - 11:21
Good point Doug. The Nexus 1000V of course is available today, but what are the other practical alternatives to VN-TAG?
Well, today you are probably stuck with option “c” above (for “creative” or for “compromise”
. But this will improve. There are startups working on better vswitches, and VMware will surely improve theirs over time … and both of these will happen before your NIC vendor, server load balancer, application-aware firewall, and intrusion protection system all support VN-TAG.
In other words, VN-TAG is not a complete solution today either, and I expect the standards-based approach (of putting access-layer functions into the vswitch) will be complete much sooner because it is so much more straightforward architecturally.
The Ethernet frame format is virtually unchanged since 1980, when Ethernet went from 8-bit addresses to 48-bit addresses (and from 3 megabits to 10 megabits). 802.1q is the only frame format change since then, and it brought us VLANs and QOS which are important features. I remain skeptical that we should modify the frame format for the third time in history when the only benefit is enabling aggregation-layer switches to perform access-layer functions.
July 28th, 2009 - 09:31
having a rather interesting debate with Ken Duda on the value of tagging at a VM-level…. http://bit.ly/5aUwO
This comment was originally posted on Twitter
July 28th, 2009 - 11:41
Doug,
Great article. This is off the VN-tag topic but paragraphs 2 and 3 really stood out because of a biz-dev meeting I just had.
We were talking to a larger company about a possible partnership based on our technology which is winning market share. One of the engineers on their side was stonewalling us in the meeting because we are not standards based.
We tried to explain to him that the current standard is unable to solve the problem which is why we went away from it. Still he was stuck. I got the feeling that this guy never talks to customers and may be a member of the standards committee.
Good example of the tail wagging the dog.
July 30th, 2009 - 19:29
@dgourlay – This seems like a pretty simple equation to me. If you’re big enough to fund the R&D (ie. Cisco) and you can solve enough new problems (ie. ISL with router port counts, SCCP for IP Telephony call-control), then the reward is a 2-3yr advantage in the market for the vendor and a near-term solution for the customer.
It could also backfire if there is enough customer pushback. It’s not a given.
In the past, there was never another company big enough (in networking) to challenge Cisco with a competitive non-standard protocol (unlike the HD-DVD vs. Blu-Ray standards), but maybe that changes now with all the consolidation (ie. Juniper, HP, etc.) and instead of a tagging standard (18-24 months of bureacracy), there quickly emerges a VN-Link alternative.
@JimD – welcome to protocol battles. I made my bones with SIP many years ago.
August 4th, 2009 - 04:45
Well written post – helped understand the situation in a clear business like manner – but with enough technology content. Thank you.