faz1.com blog

August 2008 – Swordfish officially named the Nexus 1000V

VN-Link Chain

With VMworld 2009 just around the corner (August 31-Sept 3 at the Moscone Center in San Francisco) and our entire team scrambling to get ready for the show (Platinum sponsor keynote, product breakout presentations, Nexus 1000V self-paced lab, demo of upcoming Nexus 1000V release, etc), I was reminded of our preparation just 1 year ago for VMworld 2008 in Las Vegas.

We had started the Swordfish beta program in conjunction with VMW and had made a decision to publically introduce the new product and some of it’s capabilities at the upcoming show.  From a marketing perspective, we knew it was going to be part of the Cisco Nexus family, but we didn’t know if we should give it a number or not.  We had originally toyed with the idea of just calling the product the Cisco Nexus Virtual Switch, but it wasn’t in keeping with Cisco’s model for naming/numbering new network infrastructure solutions.  After a lot of back and forth with the different teams (product, engineering, marketing, partner, executive, etc), we settled on calling Swordfish the Nexus 1000V, with the “V” standing for “virtual” to indicate it was a software product.  At the same time, we also came up with the name VN-Link, although concluding on that name was quite a bit more complicated.

We needed to come up with a simple marketing term that could be used to define this new area of advanced virtual machine networking capabilities and it had to apply to both the Nexus 1000V and the optional Network Interface Virtualization (aka VN-Tag) model we were developing for our forthcoming Cisco Unified Computing System (aka UCS) which was to be launched in the spring of 2009.  The Nexus 100ov was a drop-in replacement for the VMware vSwitch in the vSphere solution and it maintained the existing location of the first hop L2 switch (in the hypervisor) and did not require any special hardware or switches upstream to function properly.  Once installed in a VMware vSphere Enterprise Plus environment, the solution  provided an advanced network feature set, a familiar and consistent network management and operations model and support for virtualization aware networking services.   These services include policy based connectivity, mobility of network & security services and a non-disruptive operations model for the server administrator.  Now the Cisco UCS with support for Network Interface Virtualiation (NIV) will also support the same features described above.  The main difference between the Nexus 1000V solution and the Cisco UCS NIV solution is that NIV model extracts the first hop L2 switch from the hypervisor and performs this function in the upstream switch (in the case of the Cisco UCS, this would be the 6100 series device).  Brad Hedlund has done a great job of illustrating this on his blog here.   The other features and benefits are consistent between the 2 solutions, something we were shooting for from a customer perspective.  The benefit of the NIV model is that the server CPU can be offloaded from having to perform any of the network functions, leaving more cycles for additional server workloads.  With this model, all packets are tagged and sent to the upstream switch taking advantage of the hardware ASICs to perform network policy enforcement and first hop L2 forwarding decisions.

Again, from a customer facing perspective, the Nexus 1000V model and the NIV model are consistent.  They both leverage port profiles to assign network and security policy to the VM vnic (assigned as a Port Group in VMW’s vCenter).  They both leverage the vSphere vNetwork distributed switch from VMware and support mobility of network and security properties and interface/flow state.  They both maintain the regular VM creation and operational workflow for the server administrator, offloading the vSwitch and Port Group configuation and management to the networking team.  And they both leverage the concept of a virtual ethernet interface (veth for short) to associated a unique network interface to a specific VM VNIC. Effectively, both of these solutions create a logical equivalent of what we see in the physical world everday  –> Server NIC, Switch Port and the RJ-45 cable that ties them together.  It’s “virtual”.  It’s in the “network”.  It’s a logical “link”.  It’s a virtual network link. It’s a VN-Link.  A great paper on VN-Link can be found here in case you want to know more.