Proof By Debug: Mastering the MQC Priority Command

Hi Everyone,

While teaching an on-line mentoring session on router QoS last night, the
discussion turned to how can one attain a deep understanding of the MQC
"priority" command, one of the key congestion management tools in the MQC.
Many consider the MQC priority command "a priority queue" but it is
technically "a strict scheduler" rather than a "queue". Since it is a
"strict scheduler", it does not "queue" packets. It will either transmit or
drop packets based upon the amount of tokens available in its token bucket.

But wait???? This MQC "priority" configuration command sounds more like a
policer than a congestion management mechanism. Instead of simply
discussing this topic, you can use the IOS to make QoS theory come alive!!!
We can apply what we love to call in our live mentoring sessions "proof by
debug" using the insightful debug tool "debug priority".

Here is what you do to develop a deeper understanding of the MQC "priority"
command:

1). Create a simple three router test bed, one source router, one router in
the middle configured with the MQC and one target router.

2). Make the link between the source and the MQC router in the middle a
relatively high speed link - an Ethernet segment will work fine.

3). Make the link between the target and the MQC router in the middle a
relatively low speed link - a Frame segment will work fine. Set the clock
rate on this link to about 72000 bps.

4). Generate traffic with 1-2 IP SLA sessions. We like to use two jitter SLA
sessions and send about 30000 packets at 10ms intervals. Mark each SLA
session with a unique TOS value to differentiate the traffic that will be
processed by the MQC priority scheduler. When these SLA sessions are
transported over this simple topology, the MQC mechanism configured on the
middle router will experience congestion.

5). Generate traffic for the MQC priority scheduler with an extended ping.
We like to send about 1000 packets of 1000 bytes in length with a 1 second
timeout and a TOS of 160. TOS 160 = Precedence 5.

6). We create a simple class-map on the MQC router that matches on
precedence 5 and we apply this class-map to a policy-map that is configured
with the "priority command". When we configure the MQC priority command, we
make sure we set the burst parameter of this command to an amount that is
less than the test packet size, in this case the packet size is 1000 bytes.

Here is the "burst" parameter with the MQC priority command:

R2(config-pmap-c)#priority percent 10 ?

  <32-2000000> Burst in bytes

For this example let's set this burst value to 750 bytes.

R2(config-pmap-c)#priority percent 10 750

NOTE: This burst value of 750 bytes is LESS than the test packet size of
1000 bytes.

7). Here is the final step: enable "debug priority" to make your QoS theory
come alive. Here is some sample output of "debug priority":

*Oct 19 00:43:13.637: WFQ: dropping a packet from the priority queue 0

*Oct 19 00:43:14.637: now 1307893020 tokens 6000 pak_size 8032
max_token_limit 6000

*Oct 19 00:43:14.637: WFQ: dropping a packet from the priority queue 0

*Oct 19 00:43:15.637: now 1307894020 tokens 6000 pak_size 8032
max_token_limit 6000

Notice the reference to "tokens 6000" and "pak_size 8032" and finally
"max_token_limit 6000"

All of these values are in bits. When they are translated into bytes, they
make much more sense. Let's do this:

Tokens 6000 bits = tokens 750 bytes

Pak_size 8032 bits = packet size 1004 bytes

Max_token_limit 6000 bits = max_token_limit 750

Once this bits to bytes conversion is performed, "proof by debug" clearly
shows the issue: the MQC priority burst value is less than the packet size.
Therefore, ALL 1000 byte packets - and all packets larger than 750 bytes -
will be dropped by this configuration.

Moral of the story: make sure your burst parameter for the MQC priority
command is always larger than the packets that it is processing. How do we
know this?.... Well of course by... PROOF BY DEBUG!!! : )

HTH,

-Bruce

Andrew Bruce Caslow, CCIE #3139

+1 703 606 7353

NetMasterClass, LLC

Cisco 360 Master Instructor

Cisco Learning Partner

www.NetMasterClass.com

NMC Live On-Line Group Mentoring Sessions held on Mondays at 12 noon and 7
PM and Fridays 12 noon and 6 PM (GMT -5). All Live On-line Group Mentoring
sessions are 90 minutes each. Come join us for more Proof by Debug!

Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 19 2010 - 12:01:18 ART