Bridging the Network Gap: Cisco Nexus 5000

Policing with a Policy

Obviously, the most important novelty that the Nexus 5000 brings to a datacenter and the greatest differentiator with other, single protocol switches is that Ethernet and FC are just two supported applications that you monitor and control from the same administrative interface.

With that in mind it's easy to understand why the Nexus runs a new OS, the NX-OS, which, according to Cisco, inherits and brings together the best features of their Ethernet-focused IOS and their FC focused SAN-OS.

To access the OS features administrators can choose between a powerful CLI or the GUI-based Fabric Manager. I used the plural because the administrative tasks of the switch can be easily divided between multiple roles, each with a different login and confined to a specific environment, as defined by and under the supervision of a super admin. That's a critical and much-needed option if you plan to bring multiple administrative domains and their administrators under the same banner.

This and other configuration setting of the Nexus 5000 are policy-driven, which makes for easy and transparent management. Another remarkable feature is that you can define classes of service that logically isolate different applications.

For example, after logging in to the switch, a simple command such as "sh policy-map interface Ethernet 1/1" listed all traffic statistics on that port, grouped for each CoS (class of service) and listing separated numbers for inbound and outbound packets.

Combining a certain CoS with a proper policy, an admin can not only monitor what traffic is running on the switch but can also automatically control where packets are routed and how. Load balancing is a typical application where that combination of policy and QoS shines, but there are others -- for example, automatically assigning packets with different MTU to different classes of traffic.

The NX-OS makes easy some otherwise challenging settings, such as mirroring the traffic flowing on one interface to another on the same or on a different VLAN. A similar setting can be useful for sensitive applications such as surveillance and remote monitoring, but can also help test the impact of a new application on a production VLAN.

Defining a correct policy can help also make sure that FC traffic, or any other traffic running on the 5000, will never drop a frame. Dropping a frame is obviously a mortal sin if a storage device is at one end of the connection, but other performance-sensitive applications can benefit from uninterrupted transport.

I was surprised to learn how easy that was to set up with just a handful of commands:

class-map critical

match cos 4

policy-map policy-pfc

class critical

pause no-drop

system qos

service-policy policy-pfc

In plain English this means the following: Never drop a frame and pause the traffic if you can't keep up with the rate.

I should also mention that PFC stands for priority flow control, a new feature which is at the heart of the FCoE protocol and essentially makes Ethernet able to survive traffic congestion without data loss, by pausing the incoming flow of packets when needed.

My next command, a line that I am not showing, was to assign that policy to two ports on my switch.

Subscribe to the Business Brief Newsletter

Comments