faz1.com blog

When we started submitting abstracts for VMworld 2009 earlier this year, I didn’t really think it would involve more work than what we had put into the show last year when we announced the Cisco Nexus 1000V.  Boy, was I wrong.

Just for the N1K alone (not to mention all the UCS related activities at the show), we need a small army of people to develop and support the N1K self -paced lab SPL23:

Han is working on developing an all new breakout presentation which will be run on Wednesday (3:30PM) and Thursday afternoon(TA2384).  You can watch a short intro for the presentation here:

We are also working on new content for a bunch of stuff going on in the Cisco booth including a preview of some new features of the Nexus 1000V (ask us about Virtual Service Domains – VSD, a very cool feature), detailed demos of the currently available product and lots of short presentations covering different technical and business aspects of the product including:

• Introduction to the Nexus 1000V
• Securing the Virtualizated Data Center with the Nexus 1000V
• Doing More with Less with the Nexus 1000V
• High Density VM Deployment with the Nexus 1000V
• Nexus 1000V and Intel VMDq
• Virtualized Data Center Performance Monitoring

Looking forward to seeing everyone at the show!

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.

Swordfish Beta 1 Delivered – July 2008

Before this program, I never realized how much work is involved in getting customers to actually test and provide feedback on a new product, especially a software add-on to another company’s product.  Swordfish’s success was dependent on a successful beta cycle of VMware’s next generation product in the 2nd half of 2008 and 1st part of 2009 (to be known as vSphere) and customer’s desire to evaluate the new features.  To make matters even more difficult, because of customer confidentiality agreements already in place, the 2 companies could not share beta customer information.  Since the Swordfish beta was to be run as a “add-on” beta program to the vSphere beta, we (Cisco) needed to approach customers one by one who we knew were interested in Swordfish and possibly participating in the vSphere beta program already.  Sometimes we got lucky, sometimes we struck out, but overall, this “beta on a beta” proved to be very difficult from a logistics perspective.  Looking forward, my goal would be to find a way to run subsequent beta programs on a version of vSphere that has already GA’d to dramatically simplify the customer engagement process.  This wasn’t an option with Virtual Infrastructure 3 because of the lack of the vNetwork Distributed Switch functionality (which was known at the time as “distributed virtual switch”).

In parallel to figuring out the beta process with VMware, the team was busy with nailing down the the business arrangement to ensure that 1) both Cisco and VMware could embrace this co-development effort as a win-win (not very easy when you have two 800lbs gorillas sitting in the same room, neither wanting to move away or give on the terms they normally require in any agreement) and 2) the solution would result in something easily deployed and adopted by our mutual customers.  Flexibility, lots of hard work, many late nights and some ingenious engineering efforts on both sides went into pulling this off, and it was certainly aided (from my perspective) by the initial feedback we were starting to get from joint customers.

So what was the initial feedback from customers?  It was extremely positive.  There were only a few features supported in the beta 1 program, but one of the key innovations that the Swordfish engineering team had developed (a feature called Port Profiles) was starting to catch on with customers.  This feature allows network administrators to configure/set network policy for virtual machine environments and then expose a collection of these network policies to the server administrator through VMware’s vCenter tool.  Port Profiles would enable network, security and server admins to embrace server virtualization like never before, allowing the functional data center teams to respect each other’s configuration and operational boundaries.  This is a critical capability if customers are going to attempt to virtualize 100% of their applications in the next few years.

As the positive customer feedback continued to come in, we worked with VMware to figure out if we wanted to introduce this new concept at the upcoming VMWorld show in Las Vegas in September of 2008.  The goal was to create awareness for the new technology and pave the way for an even broader phase 2 beta program (the biggest in Cisco’s history) and successful product launch.  The 2 companies agreed that this would be a great step to take and the planning began for a September technology launch.

The next chapter

Chapter 4: August 2008 – Swordfish officially named the Nexus 1000V

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

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)