Welcome to this week’s Ticket of the Week segment or TOW for short. TOW is where I cover a range of hot topics and trends from within the industry that include actual examples of tickets from previous employers and clients edited only for confidentiality reasons. Have a suggestion please use the contact page and someone will get back to you promptly and you may be featured in the segment. This weeks topic? Cisco Nexus.
First let me start by saying by no means am I writing this post as if the Nexus is some new technology because it’s not. The first Nexus switches were introduced more than ten years ago in January of 2008. Designed to be an end-to-end data center solution I’d say Cisco has delivered on that claim. Cisco built the nexus switch to deliver the highest level of scalability and availability. A new, at the time, operating system NX-OS also debuted featuring some key differences to the standard IOS and some distinct advantages as well. Inevitably that means for the engineers and operators out there, Nexus comes with a learning curve as well. How steep? Well that depends on the individual.
For those with a solid foundation in IOS, the transition is relatively painless. Cisco even has this wiki document to help ease the transition for those already well versed in IOS. However Nexus being around for 10 years isn’t enough to magically make all operators fluent. One must be in an environment that uses the equipment frequently to truly become experts. The same can be said for all platforms though. In recognizing this, Cisco rolled it’s Cisco Data Center series of certifications, which start at CCNA and go through the CCIE level. Having gone through the course myself it’s a good way to get your feet wet and to increase your skill set. More details can be found here regarding the CCNA exam and the CCNP exam.
Aside from the slight differences there’s also some new elements that come along with the Nexus platform. Chief among them, and a personal favorite is FabricPath. Fabric path differs from traditional switching because the topology is identified by a switch-id. Said switch-id is then used to populate the layer 2 forwarding tables instead of the traditional MAC address. The significance of this is that, by using IS-IS FabricPath does not use spanning tree. Eliminating spanning-tree opens up the possible to build large and scalable layer 2 networks in ways, we previously could not due to spanning-tree’s limitations. Maximum bandwidth, scalability and resiliency are now a reality thanks to FabricPath and the Nexus series of switches. FabricPath is also designed to play nice with other existing Layer 2 technologies including vPCs. Most importantly you gain all of these benefits while simplifying your network across the entire Data Center.
Virtualization is another key benefit of NX-OS. In the prior paragraph I mentioned vPCs, which are Virtual Port Channels. Virtual Port Channels servers or other downstream switches can now connect to an upstream switch without spanning-tree blocking any of the ports. Basically vPCs are what allows the Nexus platform to truly maximize your bandwidth. With a vPC that’s say 4 x 10gps, on two switches for a total of 8 x 10gbps, you will have the full 80gbps available as opposed to a traditional spanning-tree setup. With spanning-tree your available bandwidth is basically slashed in half for a true total of 40gbps across both switches. Because, as my seasoned readers know, spanning-tree treats port channels as a single port regardless of their membership. Also, vPCs do not have to be connected to the same device, but are still presented as a single link. There’s also a functionality called vPC+ that allows legacy type Ethernet devices to be added to the FabricPath topology or cloud if prefer that term. For the uninitiated I’m sure you’re beginning to sense the benefits and intrigue surrounding the NX-OS.
Keeping with the virtualization aspect of the Nexus brings me to VDCs or Virtual Device Contexts. VDCs allow you to partition a single Nexus 7000 (7K) switch into multiple virtual devices. Benefits of having VDCs include fault isolation, an additional means of separating traffic, an administrative partition, simpler management and greater security. For example say you have your main engineers who implement your networking solutions. Those engineers could have access to the 7K and all of its VDCs. For example let’s just use “production “and “non-production”. Junior engineers could have access to the “non-production” VDC while your senior engineers handle the “production” VDC. I admittedly used a pretty simple example but this isn’t really meant to be in depth. If you would like to explore the topic further see this article about RBAC (Roles-Based Access Control Management).
Circling the wagon back to scalability and flexibility leads me to the last topic I’ll cover In this article which is the Nexus 2000 Fabric Extenders. More commonly referred to as just FEX modules. There is also the problematic B22HP HP-FEX for HP blade systems, but more on that some other time. If you’re really curious feel free to google it and you’re sure to find some examples. But what exactly is a FEX and what makes it so flexible? Well a FEX is a better thought of as a remote line card. Said flexibility in this instance is derived from the fact that you can position a FEX almost anywhere within your environment. Just as an example the FEX could be positioned in the corners of your data center, and connected back to the Nexus in a more centralized location. Eliminating the need for several long cable runs between the servers and switches.
So for those previously unfamiliar with the King, aka Nexus, I hope I’ve provided you with just enough of a sample to explore the topic further. For those already familiar, leave a comment or send a note and share your own thoughts and opinions on FabricPath or the Nexus. I didn’t’ t dive too deep into the Nexus here and that’s by design. This post is more so an overview. More detailed post to come in the future.