Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Catalyst 2970/3560/3750—<strong>QoS</strong> Considerations and <strong>Design</strong><br />
2-58<br />
<strong>Enterprise</strong> <strong>QoS</strong> <strong>Solution</strong> <strong>Reference</strong> <strong>Network</strong> <strong>Design</strong> <strong>Guide</strong><br />
Chapter 2 Campus <strong>QoS</strong> <strong>Design</strong><br />
Note The Catalyst 2970/3560/3750 also supports two configurable ingress queues (normal and expedite).<br />
Ingress scheduling, however, is rarely—if ever—required, as it only becomes enabled if the combined<br />
input rates from any/all switch ports exceed the switch fabric’s capacity. Such cases are extremely<br />
difficult to achieve, even in controlled lab environments. In the extreme case where such a scenario<br />
develops in a production environment, the default settings of the ingress queues are acceptable to<br />
maintain VoIP quality and network availability.<br />
The three remaining egress queues on the Catalyst 2970/3560/3750 are scheduled by a Shaped<br />
Round-Robin (SRR) algorithm, which can be configured to operate in shaped mode or in shared mode.<br />
In shaped mode, assigned bandwidth is limited to the defined amount; in shared mode, any unused<br />
bandwidth is shared among other classes (as needed).<br />
Shaped or Shared bandwidth weights can be assigned to a queue via the srr-queue bandwidth shape<br />
and srr-queue bandwidth share interface commands. Shaped mode weights override shared mode<br />
weights and use an inverse ratio (1/weight) to determine the shaping bandwidth for the queue.<br />
Furthermore, if shaped weights are set to 0, then the queue is operating in shared mode. For example,<br />
the following interface command srr-queue bandwidth shape 3 0 0 0 would shape Q1 to 1/3 of the<br />
available bandwidth and set all other queues to operate in sharing mode.<br />
To make the queuing structure consistent with examples provided for previously discussed platforms,<br />
Queues 2 through 4 should be set to operate in shared mode (which is the default mode of operation on<br />
Queues 2 through 4). The ratio of the shared weights determines the relative bandwidth allocations (the<br />
absolute values are meaningless). The ratio of the shared weights determines the relative bandwidth<br />
allocations (the absolute values are meaningless). Since the PQ of the Catalyst 2970/3560/3750 is Q1<br />
(not Q4 as in the Catalyst 3550), the entire queuing model can be flipped upside down, with Q2<br />
representing the Critical Data queue, Q3 representing the Best Effort queue, and Q4 representing the<br />
Scavenger/Bulk queue. Therefore, shared weights of 70, 25, and 5 can be assigned to Queues 2, 3, and<br />
4, respectively.<br />
Additionally, the Catalyst 2970/3560/3750 supports three Weighted Tail Drop (WTD) thresholds per<br />
queue. Two of these thresholds are configurable (explicit); the third is non-configurable (implicit), as it<br />
is set to the queue-full state (100%). These thresholds can be defined with the mls qos queue-set output<br />
qset-id threshold global command. The only queues that these thresholds need defining (away from<br />
defaults) are Queues 2 and 4. In Queue 2, it is recommended to set the first threshold to 70% and the<br />
second to 80%, which leaves the third (implicit) threshold set at 100% (the tail of the queue). In Queue<br />
4, it is recommended to set the first threshold to 40%, leaving the default values for both the second and<br />
third thresholds at 100%.<br />
Once the queues and thresholds have been defined, traffic can be assigned to queues and thresholds either<br />
by CoS values or DSCP values, using the mls qos srr-queue output cos-map queue and mls qos<br />
srr-queue output dscp-map queue global commands, respectively. While DSCP-to-Queue/Threshold<br />
maps override CoS-to-Queue/Threshold maps, these mappings should be as consistent as possible to<br />
ensure predictable behavior and simplify troubleshooting.<br />
That being said, CoS 0/DSCP 0 (Best Effort traffic) should be mapped to Queue 3 Threshold 3 (the tail<br />
of the queue), as no other traffic is to be assigned to Queue 3.<br />
CoS 1 (Scavenger and Bulk) should be mapped to Queue 4 Threshold 3. Scavenger traffic can then be<br />
further contained by a DSCP-to-Queue/Threshold mapping assigning DSCP CS1 to Queue 4 Threshold<br />
1 (previously set at 40%); Bulk Data using DSCP values AF11, AF12, or AF13 (decimal values 10, 12,<br />
and 14, respectively) can then use the remainder of the queue. Bulk Data can use either Threshold 2 or<br />
Threshold 3 as its WTD limit (both of which are set to 100%).<br />
Version 3.3