A brief overview of Cisco Nexus switches.
Modern data centers arguably require a purpose-built switch to meet the unique needs of today’s data center network traffic. LAN switches had to evolve to accommodate new bandwidth, fault tolerance, latency and centralized management requirements. As a result of this technical evolution, the Cisco Nexus family of switches was born. In 2008 the first models were introduced, and soon after they took the network world by storm. Today these are probably the most common switches in server racks. For the next couple weeks I’ll be diving into a several part series introducing the Cisco Nexus family and breaking down step-by-step how to configure and deploy specifically the 5500 series switches.
To keep my posts relevant to someone new to Nexus switches, I’ll be focusing mainly on high level concepts and general configuration. I won’t be looking into architectures such as FlexPod or explaining technologies such as ACI, fabric path, or OTV. There are several narratives being told in the industry about the benefits of one design over another or one technology over another, but for the next few posts I’ll be writing for an audience that’s learning about this technology for the first time.
First, let’s examine the defining attributes of Nexus switches.
An important benefit of these switches is their flexibility to accommodate ethernet, FCoE or fibre channel, but probably the most important benefit is the Nexus’s ability to switch frames really fast. That, along with virtual port channels (vPC), virtual device contexts (vDC), and near lossless transmission over fiber channel, makes Nexus series switches almost as cool as Chris Cornell in 1994.
There are a variety of Nexus switch models currently on the market including the 1000, 2200, 3000, 4000, 5500, 6000, 7000 and 9000 series. Though the design and configuration among these is pretty similar, there are some significant differences to note. The 3000 doesn’t support fabric extenders, for example, and offers only a few 10 Gbps SFP+ ports while the rest are RJ45. The 1000 is a virtual switch extending the access layer right into the hypervisor, the 2200 series is unique in that it isn’t a standalone switch at all, the 4000 is an IBM blade center switch, and the 9000 can be deployed in standalone or ACI mode.
But for now let’s focus on the 7k and 5k.
The Nexus 7000 series switches are chassis switches normally used at the data center core providing multiple high bandwidth linecards, dual supervisors, several power supplies, crossbar fabric modules for an insane backplane and all the awesome features expected in a top-of-the-line core switch. The Nexus 7009 and 7010 are the most common, with nine and ten slots, respectively. The Nexus 7000 series uses a Unified Ports architecture providing SFP+ slots that can be configured for either 1/2/4/8-Gbps Fibre Channel or 1/10-Gbps Ethernet SFP+ modules. This modular approach gives it a similar feel to the to the 4500 and 6500 series chassis switches.
The Nexus 5500 series switches can be used at the data center core of smaller environments, but they’re also commonly used as end-of-row switches aggregating uplinks from smaller top-of-rack switches such as other 5000s, 3000s, or most commonly 2200s. The 5500 series comes in 1U (5548) and 2U (5596) form factors. The 5548 provides 32 ports built-in and has a single, 16-port expansion slot for a total maximum of 48 ports. The 5596 provides 48 ports built-in and has three 16-port expansion slots for a maximum of 96 ports. The Nexus 5548UP and 5596UP provide the ability to configure SPF+ slots for either 1/2/4/8-Gbps Fibre Channel or 1/10-Gbps Ethernet SFP+ modules. The ‘UP’ in the model name stands for Unified Ports which signifies that particular model’s ability to accommodate Ethernet or Fibre Channel.
I’ll mention the Nexus 2200 series switch here as well because it’s often deployed along with the 5k switches. A Nexus 2200 series switch is more commonly known as a fabric extender, or FEX, because it’s not configurable as a standalone switch. It is what it’s name suggests: an extension of an upstream switch in a sort of deconstructed switch fabric design. The switch is normally installed top-of-rack for server access and then homed into a 5548, 5596 or 6001 end-of-row switch or pair of switches. This allows the 5500/7000 architecture to scale easily with a centralized management capability because all FEX configuration is done on the upstream switch. Taken as a whole, the entire system is the Nexus switch fabric deconstructed throughout multiple server racks or an entire data center.
One of the more powerful features of the Nexus operating system, NX-OS, is the virtual port channel, or vPC. NX-OS vPCs allow two or more links to be connected between a device such as a core switch and two Nexus switches. To the connected device, the Nexus switches appear as a single switch. This is similar but not the same as VSS used with some Cisco Catalyst switches. vPCs allow layer 2 link redundancy but retain Nexus switch independence in the control plane.
– A simple image of a fully redundant design –
I’ve been in many data centers in which there was no redundancy at the server access layer though redundancy on several levels at the core. I’ve also seen designs in which there was access layer redundancy, top of rack redundancy but then no core fault tolerance. The above drawing is a simplified image of an ideal scenario in which servers use LACP to create port channels to each access layer FEX, and then each FEX uses port channel vPCs to dual home to disparate core switches also joined by a port channel. The cost associated with eliminating every conceivable point of failure is tremendous, but this basic design using what in 2015 is common technology provides a much more resilient application delivery medium.
The remaining posts in this series will be focused on configuring these switches in both a single-homed and dual-homed topology. I’ll introduce additional concepts when they’re relevant, but my main goal is to provide a clear guide for getting these awesome switches up and running with solid configurations. Get some more coffee, microwave a hot pocket, and follow along.
{networkphil} 
Leave a Reply