I have to admit, I'm impressed by Cisco's foresight for getting its technology inside VMware. If VMware is not a revolutionary change (close to it), it is certainly a fast-paced evolution for the IT infrastructure environment. Companies are building complete business models around VMware and IT organizations are developing news ways of operating in a virtualized ecosystem.
Furthermore, now that VMware is talking about taking over the whole DC, Cisco is wise to get in on the game. By placing Cisco IOS inside ESX, Cisco has guaranteed a place at the table and ensured its legions of Cisco engineers - the same people who buy Cisco products - a career path. That is a symbiotic relationship Cisco has to maintain. But, at this point, the Nexus 1000V is vaporware (unless someone has actually bought it??). So there are questions that need to be asked before the Nexus 1000V is more than a marketing success.
The first question is performance. The Nexus 1000V is not a Cisco switch that forwards packets in specialized ASICs for optimal performance. Now Cisco IOS is using software API calls to the ESX server to move packets, all of which relies on a general purpose x86 processor. The API calls should be interesting since API calls generally are limited and add extra overhead. From what I've read, Cisco does not have direct links into the ESX kernel, but relies on a the DVS API to provide networking services. VMware did an API to provide other companies the opportunity to provide the networking in ESX. Cisco may be the first, but I'm going to guess not the last. It will be interesting to see how Cisco optimizes the Nexus 1000V performance in this environment.
Next is stability. It may be IOS, but it's really NX-OS, which is rather new (yes, yes, I know, SAN OS, whatever...it's new). So, how will bugs be? How much different will IOS need to be in this environment since it is not interacting with Cisco controlled hardware, but ESX? Plus, the virtual supervisor module in the Nexus 1000V operates all of the EVMs in the environment. Will a crash in the supervisor affect all the ESX servers?
After stability comes integration with Cisco's physical network hardware. If I spend big money on the Nexus 1000V I will expect some sore of heightened integrations with the brand new Nexus 7000 and 5000 environment I built for all those ESX servers. It would be Nexus throughout the data center so extra features would be expected. Industry standards are a given, but what more can Cisco do now that is controls the hardware network and the software network?
The next question is about other virtualization environments. VMware gets all the press now, but there are other virtualization technologies out there, and not just Microsoft. Solaris containers are particularly useful in large compute frame environments along with IBM's PowerVM systems. Cisco needs to see beyond just the VMware hype and look at these other technologies since many companies run their most critical applications (Oracle, SAP, business intelligence) on large compute frames, not general purpose x86 servers running VMware. Missing these environments just to be on the VMware bandwagon would be short-sighted.
Finally, Cisco needs to consider the competition. Cisco has maintained its market leadership in switches despite viable competitors. What's helped has been high barriers to market entry since creating a new hardware product with all the high-end ASICs, and making it better than Cisco's, was tough. But now we're talking about software. The barriers to entry are much lower since hardware production is not an issue. A team of brilliant developers and a small lab could develop switching software for the ESX. What an opportunity this could be for Vyatta. Or how about a company like Riverbed who could port its very nice RiOS operating system to do switching and provide traffic optimization at the same time? Riverbed already has an integration effort with VMware. Would a switching module be that far of a stretch?
So, while Cisco's future is bright, this is just the beginning. There's a lot of work to do.
More >From the Field blog entries:
Cisco's First Software Switch - the Nexus 1000V
The Single Silliest Statement I've Ever Seen from Cisco
Good Jobs are Out There, the Economy is Not in Recession
Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.
Michael Morris is a communications engineering manager at a $3-billion high-tech company. His background is in enterprise WANs working with telcos and developing large-scale routing designs. He has worked on networks at government and corporate organizations, including networks at two Fortune 10 companies. In his current role, he leads a team of 10 engineers responsible for large-scale IT networking projects and architectural standards for data networks, storage area networks, IP telephony, contact centers, and security. Michael is CCIE #11733 and recently became one of the first three Cisco Certified Design Experts (CCDE) ever (#20080002). He has 11 years experience in networking and communications, including four years as a paratrooper in the U.S. Army. He has a bachelor's degree in MIS from the University at Buffalo and is working on his MBA from NC State University. In 2008, he was awarded the Network Professional Association (NPA) Professional Excellence and Innovation Award for his work on network architecture, templates and enterprise MPLS design.
Nexus 1000V
Michael,
Nice write up. You are right that Nexus 1000V is huge for Cisco and a smart move. This is also a great thing for VMWare too, in places where they have had a tough time getting VMWware out of the labs and into production with the VM level visibility and network control that the gold old Vswitch was lacking.
As for your comment about performance, you are right that Nexus 1000V is a software based switch with a CPU and memory footprint on the Hypervisor.
However you will also be able to utilize a Nexus 5000 physical switch to provide the VM-to-VM switching in leu of the Nexus 1000V. This approach utilizes the hardware switching capabilities of the Nexus 5000 in those great Cisco ASICs. With this approach the Hypervisor only needs to provide a unique tag to each VM. The external Nexus 5000 recognizes this tag and allocates a virtual ethernet interface for each unique VM and providing all the same functionality as Nexus 1000V, but in hardware, not software, and no switching burden on the Hypervisor. This approach is call VN-Link.
Cheers,
Brad Hedlund
Cisco Systems, Inc.