This is a question that constantly comes up in the classes and discussions that I’m involved in.
Part of the problem is that Cisco’s own documentation tends towards the marketing and less towards the technology. Because of that, even a lot of Cisco folks are confused on exactly what is meant by each term. Hopefully, this short summary will help.
VN-Link is a marketing umbrella term used by Cisco to describe any number of approaches to providing physical network type visibility to non-physical or non-directly attached devices. This could mean virtual machines, could mean virtual interfaces on a remote interface card (a la Cisco’s Virtual Interface Card – aka Palo), or could mean physical interfaces on a non-switching remote device such as the Nexus 2000-series devices.
Probably the easiest way to group these is by the existence of a “Virtual Ethernet Port” on a switching device that is controlled like a physical port, but doesn’t directly map to a local physical switch port.
There are two approaches currently in use that fall under the VN-Link umbrella.
The Cisco Nexus 1000V switch, which is a software-only Cisco-branded switch that rides on top of VMware’s vNetwork Distributed Switch (DVS), is considered VN-Link because it provides virtual machine level visibility and granularity in network configuration and control. Each virtual machine receives a “virtual Ethernet port” on the 1000V, which can be configured and controlled just like a physical Ethernet port would on a standard switch.
The Nexus 5000/2000 combination and the Cisco UCS Fabric Interconnect/IO Module combination both use an additional header in Ethernet frames called VN-Tag, which uniquely identifies some remote port which will receive a virtual Ethernet port on the local switch (50xx or 61xx). This causes the Nexus 2000 or UCS IO Module to act as a remote line card to the host device, and doesn’t have to be managed individually. All switching happens in the host device (50xx or 61xx). The same VN-Tag technology is used by the Cisco Virtual Interface Card (VIC, or Palo) to identify the virtual interfaces being supported by the card. With this tag added into the Ethernet frame, the host device (50xx or 61xx) can uniquely identify the source port (virtual or physical) and apply policy or configuration to it.
Note that the Nexus 1000V does not perform VN-Tag’ing – it simply doesn’t need to in order to meet it’s objective of providing VM-level visibility and control.
So both of these approaches meet the same architectural goal, while doing so with very different technologies. Even so, they both fall under the same VN-Link umbrella. Don’t confuse VN-Link, the “goal”, with the implementation.
Excellent summary, right on point. And you’re right, there is a lot of confusion on this.
So, I will take the blame for the confusion, since VN-Link was my bright idea. The reality was we had two ways to providing VM networking that accomplished the same thing, but in different ways because they evolved in different parts of the company (hey, we’re a big company). We were looking for a way to decouple the functionality (VN-Link) from the underlying technologies (N1KV or VNtag) and also ensure customers did not feel like they had to choose between approaches (a la Blu-Ray vs HD-DVD) or be stuck with architectural or functional inconsistency. As more of out VM networking technology unfolds, this will make a bit more sense.
Well, now you know the background at least. 🙂
BTW, your explanation was spot on.
Regards,
Omar Sultan
Cisco
Omar –
Thanks for joining the discussion! Always glad to have knowledgeable folks. Hope to see more from you!
– Dave
So if I get Palo, I don’t need v1000?
Shea –
Not exactly. They’re both accomplishing the same basic goal, but are very different implementations and have different capabilities. For example, the Nexus 1000V will allow you to place ACLs on individual virtual Ethernet ports, while currently the Virtual Interface Card (VIC) only works with the UCS Fabric Interconnect – and it doesn’t have the ability to configure ACLs. There are also limitations as to how many interfaces the VIC will support, while the Nexus 1000V is for all practical purposes (as in, how many VMs you can have on a host anyway) unlimited.
You need to consider specifically what you’re trying to do, and choose the right solution. There are also scenarios where the combination of the VIC and Nexus 1000V are appropriate. I highly recommend checking out Brad Hedlund’s blog, http://www.internetworkexpert.org, as he has some great posts on the differences and use cases for both the VIC and the 1000V.
Specifically, take a look at:
http://www.internetworkexpert.org/2009/08/11/cisco-ucs-nexus-1000v-design-palo-virtual-adapter/
http://www.internetworkexpert.org/2009/10/23/simple-use-cases-for-network-interface-virtualization/
Plus, he’s got a ton of other great posts. Check it out!
– Dave
Thanks for post this explanation!