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.
How to fill up a 10G line
If setting that policy up was easy, testing that it was actually working was a bit more complicated and called for using the powerful features of IP Performance Tester, a traffic generator system by Ixia. One of the problems I had to solve was how to create significant traffic on my 10G connections, which is where IP Performance Tester, luckily already installed in my test system, was called to action. This isn't the only test where I've used IP Performance Tester, and I've found it to be a valuable tool.
For my PFC test, the Ixia system was set to generate enough traffic to cause a level of congestion which would have translated, without PFC, into losing packets. The switch under test passed this test with aplomb and without losses, proving that not only FC but also Ethernet can be a reliable, lossless protocol.