Archive

Posts Tagged ‘VN-Link’

VN-Link Evolution Chapter 2

June 15th, 2009 No comments

Swordfish Starts Swimming – January 2008

In January of 2008, the Swordfish engineering team delivered the first NX-OS based proof of concept for what would ship as the Nexus 1000V for VMware’s vSphere 4.0 almost 1.5 years later.  This proof of concept, named “Sailfish”, leveraged the same OS that was being used to run the new Nexus 7000 Data Center Switch, known as NX-OS.  NX-OS (Nexus Operating System) is a data-center-class operating system that combined the best of Cisco’s IOS and SANOS with a data center focused feature set to meet the demands of the virtualized data center.

Sailfish, from an architectural perspective, leveraged NX-OS to provide a Cisco CLI for the existing VMware ESX 3.5 vSwitch.  This basically allowed the operator to use the familiar Cisco IOS interface to configure and provision the VMware vSwitch.  A key feature of this Sailfish was the ability for a single Cisco NX-OS instance to manage many vSwitches across separate ESX 3.5 hosts, a feature that would be delivered more than a year later in vSphere 4.0 known as the vNetwork Distributed Switch.

For the next 3 months, we used Sailfish as a demonstration with key customers around the world to validate that what we were doing with Swordfish was something that they would actually deploy if a product was ever actually built.  The feedback was largely positive, but also a little mixed.

Our original assumption was that customers would be attracted to this type of product because Cisco could provide more features (QoS, ACLs, NetFlow, ERSPAN, etc) than the basic vSwitch and we found this to be accurate.  What we also found was that customers were looking for more operational tools (management, monitoring, diagnostics etc) as the virtual access layer was continuing to grow both in size and in complexity as the percentage of virtualized workloads continued to grow.

With overwhelming positive response from our proof of concept vehicle, it was time to get back to work on delivering the first beta of the final product to support VMware’s next major release.

The next chapter…

Chapter 3: July 2008 – Swordfish Beta 1 Delivered

Categories: VN-Link Tags: ,

VN-Link Evolution Chapter 1

June 6th, 2009 No comments

Two exploratory programs are merged at Cisco – June 2006

VN-Link “the name” was born in the summer of 2008, but the concept was developed several years earlier and formally established as a program at Cisco in June of 2006.  Two separate groups inside of Cisco had been working on ideas to introduce Cisco networking capability to the virtual machine environment.  At the time, these two groups were concerned that server virtualization would lead to the eventual reduction in the number of data center switch ports that the market would need and move the span of control of the largest volume of ports (the access layer) to something Cisco didn’t provide.  This would be bad for Cisco and all network vendors who did not find a way to monetize the “virtual network” evolution.  What was interesting at the time was that we were actually seeing the opposite effect…data center access ports were growing FASTER than expected due to the fact that virtualized hosts required 2-3 times as many physical NICs as a non-virtualized servers and in 2006-2008, customers were still investing in both models.  This trend slowed dramatically in  2008 as economic downturn pushed customer’s focus more exclusively on highly optimized virtualized servers and spending literally stopped on non-virtualized servers.  But I am getting ahead of myself, how did VN-Link start?

In early summer of 2006, the 2 programs inside of Cisco which were both exploring this space (and for a while didn’t know about each other…common for a big company with lots of R&D efforts) were merged into 1 program with the purpose of formalizing a plan to develop a proof of concept for a Cisco “softswitch”.  For a while, the program was simply knows as “softswitch” but we eventually decided we needed a proper name.  Ironically, the eventual name of the program (Swordfish) was actually thought up by mistake in the hallway on the way to the meeting which was to decide if the “softswitch” program would be funded or if it would die.  That conversation went something like this:

Ram: “Hi Tom, are you going to the softswitch meeting?”

Tom: “Swordfish? What Swordfish meeting?

Ram: “Not Swordfish, softswitch.”

Tom: “Oh yes, the softwswitch meeting, yes I am going.”

Ram: “I think we just came up with our program name — Swordfish!”

As a result of that meeting, the program got a formal name and actual funding.  What was interesting was how the program was actually funded and staffed.  Initially sponsored by then Cisco SVP Jayshree Ullal (now CEO at network startup Aristra Networks), Cisco SVP John McCool (who currently runs the Catalyst 6500, 4500, NX-OS, MDS & Nexus 7000 products), Cisco SVP Tom Edsall (hardware mastermind behind Catalyst 6500, MDS 9500 and Nexus 7000 products) and former Cisco NMTG CTO Paul Gleichauf (who is now working on lots of top secret things over at Apple), Jayshree decided to implement a R&D tax on all of the major business units she ran to get the Swordfish program funded.  With that, we were off to build a proof of concept for our newly funded “internal startup”.

In an attempt to keep our engineers from being poached, I am going to stick with first names as I introduce the team.  Folks familiar with Cisco will know who I am talking about.  The team started as 2 physically diverse groups (team San Jose and team Minnesota – yes, there are good engineers in Minnesota, really good!). Team San Jose was made up of Saravan, Michael, Paul, Ram, Michelle and me.  Team Minnesota was made up of Mark, Dave and Tim.  Over the course of 2006 the team got really good at using collaboration technologies to get stuff done.

So now that we had a team to build a proof of concept, we needed a hypervisor platform to run this new softswitch on.  It was a very easy decision at the time, and I would argue that it still would be an easy decision today (mid 2009).  The VMW ESX 3.0 solution was on the market and customers where deploying it faster than any other new data center technology.  From my perspective, this was when x86 server virtualization really began going mainstream and 80% or more of the market was going with ESX 3.0 Enterprise.  We had our hypervisor, now we needed to convince VMware that this was a good idea for them and their customers.

Why would VMware want our softswitch in their hypervisor?  After all, they already had one of their own already (the VMware vSwitch).  Well, with the introduction of ESX 3.0, server administrators started facing push-back from network administrators.  This wasn’t because the network administrator didn’t support the use of the new technology, but rather was a result of some of the infrastructure and configuration changes required to support the new hypervisor deployments.  For instance, network administrators have been driven for years not to trunk multiple VLANs to server NICs and this was a common deployment best practice for ESX.  Also, the network admins were usually held responsible for application connectivity issues and ESX vSwitch didn’t offer the operations, management and diagnostics toolkit needed to operate the virtual network access layer like the physical.  These types of issues kept popping up during VMware sales calls and their account teams didn’t have a solution.  We initially dubbed customers with these types of objections “the CCIE types” but both companies quickly realized that the challenges previously described were not isolated issues.  I was seeing this same sort of feedback in during customer briefings on the Catalyst 6500 (prior to working on Swordfish, I was the data center hardware product manager for that platform).  At some point, our and VMW’s respective light bulbs went off and we agreed that this co-development effort would be mutually beneficial.

Over the next few months, Cisco and VMware developed our budding business relationship around the Swordfish program.  This turned out to be an interesting and often challenging relationship.  Both companies were used to getting exactly what they wanted from partners (in other words, having it their own way) and this co-development effort, if it was to ever take off, needed to be one of equals.

The next chapter…

Chapter 2: January 2007 – Swordfish Proof of Concept Delivered (Sailfish)

Categories: VN-Link Tags: , ,

What the hell is VN-Link?

May 27th, 2009 No comments
  1. What does VN-Link stand for? –> Virtual Network Link
  2. What is VN-Link? –> A logical equivalent of a NIC, a switch port and the RJ-45 CAT cable that ties them together
  3. When was VN-Link introduced? –> VMWorld 2008 (September 16th to be exact) as part of the joint Cisco Nexus 1000V & VMware vNetwork Distributed Switch announcement
  4. What products support it? –> Cisco Nexus 1000V, Cisco UCS
  5. What can I do with a VN-Link? –> 3 things: 1) apply network and security policy to a VM VNIC before the first L2 switch forwarding decision is made.  2) provide dynamic mobility for VETH interface configuration & statistics to correspond to a VM migration event. 3) manage your virtual machine network infrastucture in a consistent manner as your physical network infrastructure while making life easier for the server administrator.
  6. Why does VN-Link matter? –> VN-Link revolutionizes how customers deploy, monitor, & troubleshoot virtualized data centers.
Categories: VN-Link Tags:

VN-Link Evolution

May 25th, 2009 No comments

My current project is the VN-Link Evolution story.  I have been working on this project for so long that I was starting to forget details about how it got started, so I decided to go back to the beginning and recount how VN-Link and the Swordfish (Nexus 1000V) came to be.

  • Chapter 1: June 2006 – Two informal exploratory programs are merged
  • Chapter 2: January 2008 – Swordfish Proof of Concept Delivered (Sailfish)
  • Chapter 3: July 2008 – Swordfish Beta 1 Delivered
  • Chapter 4: August 2008 – Swordfish officially named the Nexus 1000V
  • Chapter 5: September 16 2008 – External Nexus 1000V Launch (VMWorld 2008)
  • Chapter 6: December 16 2009 – Nexus 1000V Beta 2 Delivered
  • Chapter 7: January 31 2009 – Cisco & VMW ship RC code to customers
  • Chapter 8: April 21 2009 – VMware Launch of vSphere, Cisco Launch of Nexus 1000V
  • Chapter 9: May 21 2009 – General Availability of Nexus 1000V and VMware vSphere
  • Chapter 10: June 12, 2009 – Nexus 1000V added to the VMware Price List
Categories: VN-Link Tags: , ,