2 September 2010

Is the Cisco Nexus 7000 Needed Today – Or Tomorrow ?

New OS, New technology

It is a given that this product has been extensively tested, and will work as described, probably with a small number of the usual glitches. Cisco commitment to software testing that commenced around 2004 / 2005 has definitely reduced the number of significant problems in the field. I do not believe that we will see repeat of the IOS 12.1.5T where so many features were introduced and took years to finally stabilise. Notwithstanding, NXOS is new and needs careful consideration. Currently, I am most concerned about integrating NXOS into my current NMM platforms. I suspect that Cisco will have addressed this at some level by deliberately maintaining SNMP MIBs and the IOS CLI but NXOS will have different considerations for CPU, memory, and other key monitoring variables that will take some time to adopt.

Fibre Channel Over Ethernet (FCoE)

The move to integrate FCoE into the Supervisor is not entirely unexpected. It is in Cisco’s interest to leverage their strength in Ethernet switching to extend the market share of the SAN market. However, what is striking is that Cisco has delivered a FCoE solution before the standard is completed. But Cisco has made this a key part of their marketing message.

Cisco is a regular player in the standards bodies, and we have seen Cisco deliver technologies such as HSRP and ISL, long before IETF / ANSI / etc have even started standards process. The key difference here is that no interoperability was ever needed. Thus HSRP only worked on Cisco Catalyst switches.

FCoE requires to co-operation of companies who are notoriously closed organisations. Indeed, Fibre Channel SAN can be viewed as a move by Storage vendors to make sure that they owned the entire solution to maximise their control of the customer (probably to the customer’s cost). Is it reasonable to expect that EMC and NetApps are willing to forgo the revenue of Fibre channel adapters and switches ?

Approvals and Validation

One of the greatest mysteries to me, is how Storage Vendors have convinced their customers that validation is a prerequisite for support. This seems an archaic concept harking back to the halcyon days of mainframe, and definitely not for the better.

Every storage equipment purchase is regularly vetted by the vendor (or worse, vendors) and long lists of “approved equipment” are consulted prior to any purchase. And yet, in networking, we have no requirement for this process. Our standard are clearly defined, and the market quickly disabuses vendors from introducing incompatible features.

Quite why testing and validation takes months is also a mystery to me. The acquisition of VMware by EMC has seen a marked rise in this problem. Not too long ago, VMware was used on any equipment, and supported by VMware.

Is Cisco going to gain these approvals in time for us to use Fibrechannel ? Are EMC / NetApps / VMware going to support them ? Also, will there be quality drivers for Windows Server 2008 and 2003 ? These unknowns are a concern to me.

Networking versus Storage

For very large data centres, the Nexus will take a long time to reach acceptance. The merger of Storage and Networking people into a single team will take some time due to human resistance to change, and the the changes to operational procedures will take a long time to achieve.

Storage people will have a lot of personal investment in storage products both in terms of experience and certification, and professional pride. Also, they are resistant to change, some pockets are deeply hostile to new advances.

The critical nature of storage means slow take up of the new. Comments such “we trust EMC” or “NetApps is proven reliable” and “compliant” and “certified” are often heard.

While I agree that this has happened before with TDM Telephony to VoIP, this is no guarantee that the convergence of storage and network is a foregone conclusion.

Nothing to Lose

It is worth noting, that due to the architecture of the NXOS a a fully virtualised core, that if FCoE doesn’t gain acceptance, then Cisco can just remove it from the software. The software will still be a monster Ethernet switch platform and Cisco will only lose the investment in FCoE not the entire platform.

Penetrating the Server Farms

Still this represents a major shift for Cisco, which has struggled to make its presence felt in the Storage space (although they claim to have 50% of the space that VSAN space that MDS occupies). Since SAN are largely the preserve of the server teams, Cisco – as a network company – may have difficulty gaining mindshare. I note that Intel has put a lot of weight into FCoE, so Cisco is not alone here.

Early Upgrades – how many ?

The first versions of the Nexus 7000 have a capacity of 230Gbps per slot, but the total slot performance is an order of magnitude larger than that. Logically this means that Supervisor and Line Card upgrades are going to be part of the lifecycle to reach to higher performance.

This isn’t new. People who purchased the first Catalyst 6000 units have had eight or nine upgrade cycles to reach the maximum capacity of the chassis. In 1999, the first Supervisor 1 supported switching only and had a 32 gigabit per second shared backplane. It took a few years before we had the fabric switching modules and routing supervisors (using feature cards) and five or six years until we got to the 20 Gbps per slot capacity that we have today, and the first high speed modules were really expensive.

The most important fact that I remember, was the first two or three years was an endless cycle of upgrades to get the basic features that I wanted. As an old (not bold) engineer, I am wary of entering this cycle again.

Missing Features – so many….

There are so many features missing in the product. MPLS is one the biggest, you need to look really carefully to realise that the current version does almost nothing but switching and the most basic routing. Once you realise this, you can only position the NX7000 as either a high speed ethernet switch in your data center core for terminating 10GE, or as an access switch for servers that are using 10GE where, hopefully, you might even be using FCoE. Spending several hundred thousand dollars on an access switch is going to be difficult.

Splash the Marketplace

If you accept my previous comments, then I believe has Cisco released the NX7000 following reasons:

  • to head off the entry of other 10GE vendors such as Juniper, Woven and Foundry to their customers. ( This also will scare off further venture capital funding on 10GE )
  • to put the product into the design pipeline of corporates and service providers, in the expectation that deployment will probably start in two to three years, by which time the features have been delivered.
  • to show commitment to FCoE and provide marketing impetus. Some customers will assume that if Cisco does it, its going to be big (and most likely they will be right).
  • to shake up the storage marketplace, and get the customers asking the Storage companies to release FCoE products, with approvals!
  • because the C6500 is showing grey hairs. The recent VSS upgrades don’t improve performance, just extend the life of the current solution. More upgrades!
  • Fiber channel adapters and switches consume extravagant amounts of power( a big weak point). By laying out the FCoE commitment, funding for new hardware programs on FC for power reduction will be less likely.

Conclusions

It is probably too early for most of us to rush out and procure the Nexus 7000, it costs too much, it needs time for management tools to mature, and it isn’t a ‘must have’ right now. I suspect Cisco is marking out territory to prevent competition. I am unconvinced the FCoE will change the world, and concerned that many features are missing.

I think the product needs quite some time to mature before I will be ready to take the plunge.

Please rate this post:

1 Star - It\\\'s Crud2 Stars - It\\\'s Tosh3 Stars - Something\\\'s missing4 Stars - Needs works5 Stars - Good Enough6 Stars - Good7 Stars - Excellent8 Stars - Brilliant9 Stars - Astonishing10 Stars - Awesomely Godlike? (No Ratings Yet)
Loading ... Loading ...

About Greg Ferro
Greg is a Network and Security Architect / Designer / Engineer working freelance in the UK and worked for Resellers, DotCom's, Large Corporate's and Service Providers across a variety of products & Vendors. He prefers to work for end users, believes in the life cycle, total cost of ownership and that near enough is often good enough. He likes talking about himself in the first person to feel "royal", even when hosting the Packet Pushers Podcast on Data Networking. More about Greg at http://etherealmind.com/who-am-i/ and you can follow him on Twitter.

Comments

  1. Omar Sultan says:

    Greg:

    Nicely thought, well-written analysis. If you don’t mind (and since you have a blog, I assume you don’t), I thought I’d add a couple of comments into the mix. :)

    NEW OS, NEW TECHNOLOGY
    So, NX-OS is built atop SAN-OS, so we are not starting from scratch, with code that’s never been run in a production environment before. That foundation and the modular nature of NX-OS are two keys to solid, stable code.

    You are correct that we have maintained the management interfaces, so, for the Catalyst crowd, there is an IOS-like CLI that maintains the existing command structure, syntax etc so there is steep learning curve. For the MDS crowd, when unified fabric modules are available, they can manage storage services with what is essentially Fabric Manager. That being said, you are correct that this platform does have different internals, so folks will have to get used to the operational norms for the new platforms

    FIBRE CHANNEL OVER ETHERNET
    So, we have built a platform that will serve the needs of FCoE–lossless fabric, storage friendly OS–we have all the pieces needed. We know what the requirements are because we are fully engaged with the standards bodies to get the standard baked. But, you will also notice, we do not have any FCoE modules because, as you point out–there is no standard yet. Its important to note, when unified fabric modules are available, you will not have to upgrade OS, fabric or supervisors to take advantage of them.

    FCoE does change the dynamics of the data center quite a bit. While some portray this as an assault on Fibre Channel, it really is not–the FC SAN is not going away any time soon. One of the things FCoE will do is give 100% of the initiators access to 100% of the targets, so it will actually enhance the role of the SAN in the data center.

    NETWORKING VS STORAGE
    Also a good point. Personally, I believe the organizational transformation challenges may be bigger than the technical challenges. We are still committed to the Catalyst and MDS, so our belief is that people will move to a unified fabric when it makes sense for them–we have no need to push. We are also working on supporting customers through the organizational aspects of unified fabric along with the technical aspects.

    As far as storage folks specifically, as I noted earlier, a unified fabric actually enhances their value-add. Beyond that, much like the transition from TDM phones to VOIP, voice teams did not go away, we just simplified the transport. FCoE, or iSCSI for that matter, is similar–FC is not going away and we still need storage services and storage architecture, etc, we are simply consolidating the transport.

    PENETRATING THE SERVER FARMS
    I think the trick here is to have something interesting to say to the server people–something we have not always done or done well. I think, when the time comes, we will have some compelling messages for them.

    EARLY UPGRADES
    I think you will be pleasantly surprised on this front. For example, we have loosely coupled the data plane from the control plane, so taking advantage of next-gen fabric modules does not imply a supervisor upgrade or I/O module upgrade–we call this forward investment protection.

    MISSING FEATURES
    The Nexus is not meant to be a universal replacement for all switches. Our belief is that you need to take a portfolio approach to find the correct switch for the particular needs of piece of your data center , so as cool as the Cisco Nexus 7000 is, you will still need rack switches, integrated blade switches, GE capability, 10GbE capability, etc. I actually believe this is a strong point for Cisco: there is a great amount of design flexibility across the Nexus 7000, Catalyst 6500, Catalyst 49xx, Catalyst Blade Switch 31xx/30xx, Cisco 7600, etc while still maintaining consistent management, operations, and features.

    Also bear in mind that the Nexus is a new family–the Cisco Nexus 7000 is the first in the series, but there will be other form factors focused on other parts of the data center network.

    Well, that’s about it–hopefully this adds to the discussion. Feel free to ping me if you have any questions.

    Omar

Speak Your Mind

*