faz1.com blog

As the deployment of 10G switches gains traction, the case studies, 3rd party “independent” test and rebuttals are flowing like mad.  I thought Omar Sultan from Cisco did a very good job with this one (rebuttal to a recently published Network World article) in particular in making the case that while 0-60MPH testing is certainly interesting, the majority of us drive on highways, back roads, traffic jams, parking lots, bridges, tunnels, and a variety of other places which require our cars to be good in a lot of different scenarios, not just on the drag strip (although, as a amateur track enthusiast, I love taking off fast).

http://blogs.cisco.com/datacenter/comments/the_perils_of_equipment_testing/

Net-net, network devices need to be able to perform well in a variety of scenarios, not just on the drag strip.  A test drive is the only way to determine if a “car” is right for you.

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.

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)