nx.os.and.cisco.nexus.switching.2nd.edition.1587143046

performance could suffer and packets could be dropped because of inconsistent QoS
policies.
The network-qos used to change the systemwide QoS policy is configurable only in the
default or admin VDC.
As of the writing of this chapter, you cannot change CoS-to-queue mappings in a device that
has a VDC with a mix of M1/M2/F1 modules. This capability changes in future software
releases, and it would be best to check the documentation on Cisco.com for release-specific
information.
As illustrated, the Nexus 7000 offers a rich set of QoS features for network administrators
to take advantage of. Comprehensive queuing, classification, and scheduling are available
and depending on the modules used will determine configuration specifics.
QoS on Nexus 5x00
The Nexus 5x00 series of switches provides a full set of QoS mechanisms for network
administrators to deploy. The QoS implementation follows the MQC described earlier in
this chapter. QoS capabilities between Nexus devices can vary based on hardware and
software capabilities. This section focuses on Nexus 5x00-specific configuration.
Forwarding Architecture
The forwarding architecture of the Nexus 5000 uses the concept of virtual output queues
managed by centralized arbitration to forward traffic across the internal components of the
switch. The Nexus 5x000 series switches uses a Unified Port Controller (UPC) to connect
into the crossbar fabric to create a three-stage switching fabric. This architecture enables
the switch to manage traffic across the switch in a granular fashion and avoids a situation
referred to as HOLB. HOLB can occur in a fabric when congestion on an egress port
prevents (blocks) ingress traffic bound for other destinations. One of the goals of the Nexus
family of switches was to engineer a platform that would avoid HOLB. In addition, the
ability to have an arbitrated fabric enables guaranteed traffic within the switch. This enables
the switch to offer lossless services over Ethernet because the switch can ensure that traffic
will not be dropped as it traverses the switch. The Nexus 5x00 switches uses an ingress
buffered architecture, similar to the Nexus 7000 F1 and F2/F2e modules. In an ingress
buffered device, traffic is stored in ingress buffers until the egress port has capacity to
accept the traffic. The Nexus 5x00 also uses the same VOQ architecture as the Nexus 7000
with centralized arbitration from the Supervisor of the switch. Each front-panel port has
eight VOQs for traffic.
The Nexus 5x00 uses the same MQC structure as described earlier in the chapter with
network-qos, queuing, and qos policies available for configuration. Nexus 5x00 supports
eight CoS, one per CoS, and depending on the model of switch, they can have different
default settings.
The Nexus 5010 and 5020 switches have QoS enabled by default, and you cannot turn it off.
In addition, four default CoS values are defined. The first two are for CoS 6 and 7 for
control traffic, CoS 3 for FCoE, and a default Ethernet class for all other CoS values. Up to
four additional system classes can be defined to meet the network’s requirements. Because