QoS: egress CBWFQ & Shaping on 7600, SIP400

tbudge · ‎03-04-2009

Required result:

The client has a 7600 with SIP400 and 2port GE SPA running 12.2(33SRD) IOS and they want to connect it via a 1Gb Ethernet pipe to a layer3 cloud/WAN. All the tail sites also connect to the layer3 cloud at speeds of 512Kb, 1Mb, 2Mb etc up to 20Mb. They want to use QoS on their core 7600 to "shape to each remote sites WAN bandwidth and then queue the shaped traffic such that different traffic recieves higher priortity treatment in the WAN".

What I've looked at:

I'm looking to configure a two tier heirarchical MQC policy to perform CBWFQ shaping. As per CCO doco's, I intend to 'shape average {bps}' in the parent policy and then call a child policy which has 6class-maps in it which apply the CBWFQ queuing to the traffic using one 'priority' class (for LLQ) and 5 'bandwidth' classes for the CBWFQ weighting (refer attached). I have three questions:

1/ what is the best/recommended approach to the 'bandwidth' classes? Should I configure the 'bandwidth {kbps}', the 'bandwidth percent {%}' or the 'bandwidth remaining percent {%}' command? I note from CCO that only the last two 'bandwidth percent' commands provide a "minimum bandwidth guarantee" whilst the straight 'bandwidth {kbps)' command seems to just apply the CBWFQ queue servicing weighting only.

2/ Assuming I use one of the 'bandwidth percent' commands, is the percentage configured based on the overall physical interfaces bandwidth (i.e. the 1Gb GE interface in this example) OR THE parent policies shaped bandwidth (i.e. the 512Kb shapped traffic rate)?

3/ As this QoS policy will be applied to a GigEth interface I'll need to set the 'queue-limit {packets}' to make the default CBWFQ queue's larger but I can't find any good reference as to how large to set this. i.e. How can I relate the number of 'queue-limit {packets}' to a given class weighting/bandwidth?

cheers Tony

Joseph W. Doherty · ‎03-04-2009

#1 I would recommend bandwidths with percentages; that way each child policy can easily use the same policy map. I would further recommend the bandwidth remaining percent; avoids the need to allow for LLQ bandwidth and reserved bandwdith.

#2 My understanding, parent's bandwidth.

#3 Proper queue sizing can be complex. Becomes even more so if using FQ and/or WRED within the class.

Generally, we want to allow bursts, but not allow needless queue growth when there's sustained oversubscription.

For TCP, as a starting point, you might size queues for each parent policy's class at about half BDP for that parent class. Child class queues might be sized in proportion to their bandwidth allocations.

Sizing non-TCP queue depths depends much on the nature of the traffic. Assuming enough bandwidth has been allocated for the child class's "average" utilization, little queue depth should be required for traffic that's close to CBR, much queue depth might be required for very varible bandwidth VBR.