What’s the difference between VN-Link and VN-Tag?

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.

Another Book

There’s a new book on Cisco UCS that is now available for pre-order on Amazon, Cisco Unified Computing System (UCS) (Data Center): A Complete Reference Guide to the Cisco Data Center Virtualization Server Architecture (Networking Technology).   I’ve got my copy on pre-order… in my experience, anything written by this team is worth owning.   Even though I have a Kindle, I still buy my technical books in dead-tree format.  What about you guys?

A real deployment’s experience with adding hardware to UCS

One of the things we talk about in Cisco UCS is how easy is it is to expand the architecture.   Each time you add a chassis in competing solutions, you have lots of management points to configure – the chassis itself, the Ethernet and potentially Fibre Channel switching/connectivity, etc.   With UCS, it’s simply a matter of “telling” the Fabric Interconnects that the chassis is there and the rest happens auto-magically.  At HealthITGuy’s Blog, Michael Heil posts his experience in adding a new chassis to a running UCS deployment.  The rest of his posts on UCS, from a customer’s perspective, are also excellent.

Excellent discussion and comparison of UCS and HP blade offerings

Over at By the Bell, there’s a great post and commentary on differences between HP’s offerings and Cisco UCS.   As many of the comments point out, the post itself is a bit biased towards UCS, but the comments are an excellent set of discussions about the various pros and cons of the solutions.  As good as the post is, the comments (I think) are even better.   Check it out!

UCS Books

I often get asked by students if there are any other resources (beyond those I’m linking to) to get more information on UCS.

Silvano Gai, along with Tommi Salli and Roger Andersson, published a book back in March of 2009 that includes a great history of the drivers and goals behind the design of UCS.   While some of the material is, of course, outdated by now – and much of the terminology has changed and evolved, it still represents an excellent view into how the architecture was conceived and designed.   Definitely recommended if you’re planning on doing anything with UCS.

You can pick up Project California: a Data Center Virtualization Server – UCS (Unified Computing System) at Amazon.

While you’re at it, also check out Silvano’s book IO Consolidation in the Data Center (namely Fibre Channel over Ethernet – FCoE).

An interesting UCS use case…

This will the first in a number of posts I make to catch up on the great content I’ve collected and bookmarked since I got involved in UCS.

Steve Chambers over at ViewYonder posted a use case for Cisco UCS that involves using the same physical UCS infrastructure to support (one at a time) multiple customers in a disaster recovery service provider type scenario.

While I don’t necessarily agree that you’d need to have a dedicated infrastructure for each customer without UCS, I think this use case is an excellent example of how easy it is to repurpose hardware quickly and efficiently – regardless of the reason.   I’ll have another post soon discussing this very same idea when it comes to burst and redundant capacity for your various applications.

Check out Steve’s post here:


While you’re there, check out the rest of Steve’s great UCS content:



Welcome to the Unified Computing Blog.

This blog was started to provide a place for me to store the various bits of information I’ve collected about the Cisco Unified Computing System.  As a professional instructor of UCS courses, a consultant assisting in the design and implementation of UCS, and courseware developer of UCS and other technology classes, I come across a lot of excellent information.

Rather than horde that information in my bookmarks, I thought it would be useful to others if I shared the information I find, along with adding my own commentary and information.

Please feel free to join in, contribute, or ask questions.

– Dave Alexander