Cisco Nexus at the core of the corporate network

Cisco Nexus switches appeared on the market for a long time. This switch family is positioned primarily for installation in data centers. However, recently the vendor itself has begun to actively offer Nexus switches for installation in the corporate network as the core of the network. And then the question immediately arises, is the Nexus suitable for such a task? It is clear, once offered, then fit. But let's focus our attention on this a bit.


The announcement of one of the first switches of this Cisco Nexus 7000 family occurred in 2008. However, for a long time they were positioned both on paper and in minds, primarily for building a data center network. Time passed, and from the status of a strange device these switches slowly began to turn into more ordinary ones. The family of switches has greatly expanded during this time. Moreover, it has even become a bit redundant. It is not always 100% clear which Nexus should be used. Today, there are switches with a fixed configuration (Nexus 3000, 5000, 6001, 9300) and modular (Nexus 6004, 7000, 9500), switches for installation in a blade basket (Nexus 4000, B22). There are also specialized switches - factory extenders (Fabric Extenders), these are Nexus 2000 and B22. Even there is a virtual switchboard Nexus 1000V (although the word “even” is not very appropriate, since the clouds are our everything). We can continue the classification for a long time, but this is not our task.


Let's see what exactly the Nexus switch family differs from the most common Catalyst switches. Since the question is quite voluminous, consider it in large strokes. Nexus switches are primarily designed to work in data centers, where it is necessary to provide continuous “pumping” of a large amount of traffic, often with minimal delays. This is where the architectural features of the Nexus switches come from.

The “pumping” of a large amount of traffic is ensured by the presence of various ports, including at speeds up to 100 Gbit / s, as well as the performance of the internal factory. It is worth noting that there is no single switch architecture. Different Nexus models are built on different architectures. There are options for building on the basis of only the Crossbar-factory (such a factory assumes the existence of a large number of paths between switch elements - ASICs). There are options for implementing the architecture of Switch on Chip - SoC (when all the logic is inside the ASIC chip, and the packet transmission between the ports goes through the common memory inside the chip). There are also combined options - Crossbar-factory with SoC. In all cases, the performance of the Nexus switches is sufficient to transmit large amounts of network traffic.


Minimizing latency in Nexus switches is provided by architectural features. In particular, most Nexus switches provide cut-through packet switching. As we remember, Catalyst switches run in Store-and-forward mode. In Store-and-forward mode, the switch starts the packet transfer only after it has received it all. In Cut-through mode, the packet is transmitted after receiving the first 64 bytes. So, in Cut-through mode, the packet delay in the switch is always constant and does not depend on its length. Also in the fight against minimizing delays in the transmission of packets within the switch, various schemes of operation of the internal factory (superframing, queues at the entrance, etc.) are involved. For example, Superframing provides the bonding of packets to each other when they are transferred through an internal factory, which allows efficient use of the capacity of this factory. For example, delays in Catalyst 3850 switches reach 50 µs (depending on the packet size). At the same time, the delay in the Nexus 3548 switch in a special mode is only 190 ns. For the rest of the Nexus switches - 1-2 ms.


For the continuity of the "pumping" of traffic are responsible for a variety of architectural features of both hardware and software. From the point of view of iron, this is a duplication of various blocks in the device (redundant fans, several power supplies, factories, etc.). There are also various control and monitoring schemes for the switchboard components (Connectivity Management Processor, etc.), which allow you to notice problems at an early stage. From a software point of view, we have a specialized NX-OS operating system and a bunch of different functions. NX-OS, unlike the usual IOS, is a modular software architecture. Each function is performed as a separate process. So, if we have a problem, for example, with OSPF, we can only overload the OSPF process. Touch the entire system will not have to. Nexus switches support various functions that allow us to obtain a high level of fault tolerance. For example, support for the default gateway redundancy protocols (First Hop Redundancy Protocols), dynamic routing with Nonstop Forwarding, STP protocols, and so on. There is also Nexus-specific functionality, for example, the creation of virtual aggregated Virtual Port Channel (vPC) channels.

In addition to the above features of the Nexus switches, it is worth adding that they support a fairly wide range of functions specifically for this family. By and large, all these functions are dictated by the scope of the Nexus - as data center switches. These functions include the provision of converged access (FCoE protocol support), switch virtualization (Virtual device contexts - VDC: we can divide the physical switchboard into several virtual ones), and support for overlay technologies (for example, FabricPath ), as well as software-defined networks (Application Centric Infrastructure - ACI), etc.

I think it has already become clear why Nexus switches are installed in data centers. Let's try to focus all the same on the original question, namely: is it possible to put Nexus instead of Catalyst in the core of an ordinary corporate network? To date, we have not identified any contraindications. On the contrary, they noted that Nexus switches have different positive characteristics, although they are necessary primarily in data centers. Now let's look at the aspects that we need from the device when working in the corporate network.

The first question that worries: what about the command line? Do not have to relearn? In general, the answer is: no, it does not have to. The command lines are quite similar. There are features, but they are not fatal. For example, when setting up various functions, they must be initially activated using the “feature” command. Ports regardless of type are called Ethernet. The syntax of most standard commands is almost identical.

The second question is which ports can I get? Here a wide range of Nexus doesn’t limit us. Available with 1, 10, 40, and 100 Gbps ports. Many options for devices with different number of ports. Separately, it is worth mentioning that Nexus switches support connecting to themselves extenders (Fabric Extender). It is like a line card in a modular switch, only made as a separate device. By itself, the Fabric Extender does not implement any logic. All traffic is always transmitted to the parent device (a full Nexus switch). With Fabric Extenders, you can get a large logical switch with various ports. And since Fabric Extender is a separate device, we can install it as close as possible to the equipment connected to it, which provides certain conveniences when building a network. By the way, a similar solution in the world of Catalyst - Instant Access. True in the world of Nexus, the vendor went further, providing an opportunity to “pull” the switch port directly into the virtual machine. Those. it creates the illusion that each virtual machine is connected directly to the Nexus iron switchboard.



And what about the standard functionality on the Nexus switches?

If we look at the L2 functions, we will find everything we need: virtual networks (VLAN, Private VLAN), support for STP loop-prevention protocols, as well as various “guards” (Root Guard, BPDU Guard, etc.), port aggregation Port Channel, etc.

As for the L3 functions, the situation is similar: static and dynamic routing support (EIGRP, OSPF, BGP, ISIS), policy-based routing (PBR), support for the default gateway redundancy protocols (HSRP, VRRP, GLBP), GRE tunnels and etc. Supported protocols for working with multicast traffic: IGMP and PIM.

From the point of view of security features, we also have a standard set: ACL access lists (IP, MAC, VLAN), port-level access restriction (Port Security), various anti-aliasing functions (DHCP snooping, Dynamic ARP inspection, IP source guard). There are mechanisms for dealing with broadcast storms (Storm Control) and protection of the control level (Control Plane Policing).

To ensure monitoring and management, everything you need is present: SNMP, NTP, Netflow, various implementations of SPAN, Embedded Event Manager, and more. Moreover, unlike the Catalyst switches on Nexus, the ability to control via the network management protocol NETCONF, as well as running scripts based on Python, is supported.

In addition to all of the above, Nexus switches, as I noted earlier, support a fairly large range of various other technologies, albeit less demanded in corporate networks: MPLS, LISP, VXLAN, OTV, etc.

It seems like, noted the highlights. Although no, I missed the part concerning the quality of service QoS. QoS functionality depends on the platform and type of line cards. Of course, Nexus switches have their own characteristics: queues at the input, support for various flow control protocols, negotiation of traffic service parameters and dynamic bandwidth control (802.1Qbb and 802.1Qaz). However, in general, the policy setting is similar to the settings for Catalyst switches. The usual scheme Modular QoS CLI is used. The main differences are: QoS is enabled by default and all ports trust QoS values ​​in packets (CoS, DSCP). One more thing: in most Nexus switches, the priority queuing is not limited by any means, which means it can utilize the entire bandwidth (for other queues, a starvation situation is possible).

I think it's worth mentioning what's not in the Nexus switches. They are not supported stacking in any form. Although this is not a problem at all. To ensure the connection of devices in a fail-safe version to two different Nexus switches, the Virtual Port Channel (vPC) technology is used. It allows you to aggregate several physical interfaces into one logical one. At the same time, the Nexus switches, where the aggregated channel arrives, continue to operate independently of each other. Between themselves, they only synchronize the parameters and the state of the aggregated vPC channel.


Nexus modular switches do not have the ability to install service modules, as can be done in Catalyst 6500/6800 switches (for example, ASA-SM firewall module, NAM traffic analyzer module, WiSM wireless network controller, etc.). Also on the Nexus switches there is no function to transfer power over Ethernet (Power over Ethernet), in fact this is logical.

Let's summarize. From the point of view of management, problems should arise. The NX-OS console is very similar to the IOS console. With the choice of the device also will not be difficulties. The switch family is very diverse. It supports the necessary standard functionality for the switch in the corporate network as its core. So, we can connect more familiar Catalyst switches (or switches from other manufacturers) to the Nexus switch. Thus, we can safely answer the question posed at the beginning of the article: in most cases, the Nexus switch can be easily installed into the corporate network as the network core. Its functionality for most tasks is enough.

Note that the Nexus switches are still primarily positioned for data centers. And they, of course, are not a complete replacement for Catalyst switches. In most cases, we can use them in the corporate network. But not always. Care should be taken to network requirements.

In conclusion, let us touch on the price aspect. He stayed behind the scenes. Understandably, the price is a very important factor, which is often looked at first. Of course, when comparing Nexus switches with other families, we can immediately note that the proximity of the cost of solutions is achieved only for switches with 10 Gbit / s ports. You should not think that Nexus switches will be competitors with conventional switches with 1 Gbps ports. For the Nexus switch family, the standard ports are 10 Gbps ports. Be sure to consider the full cost of the switch: the cost of hardware and licenses, since licenses often give a very decent price increase. But with all this, the pricing policy of the vendor in the context of Nexus switches sometimes pleasantly surprises, which makes us think about the question posed at the beginning.