Class-Based Traffic Shaping (Cisco) specifics

If you’ve looked at the wonderful world of the Modular QoS CLI (MQC), you’ve probably come across the fact that you can shape traffic from within a policy map (in typical MQC style — class-by-class!).  This method of traffic shaping is called Class-Based Traffic Shaping (CTS).  Before CTS was around, Generic Traffic Shaping (GTS) was typically the tool of choice which shapes traffic on a per-interface basis.  With CTS, you can shape traffic on a per-class basis, allowing for a great deal of flexibility.

Class-maps (classes) have got to be one of the most flexible and intuitive traffic-matching tools Cisco has created thus far.  Access-lists are very powerful if wielded correctly.  Class maps can not only utilize access-lists, but can use Network Based Application Recognition (NBAR)!  If you’re not familiar with class-maps and NBAR, I’d suggest doing some reading in Cisco’s online documentation.

I’ve been going through the nitty-grittys of CTS and had a question that I wasn’t finding an answer to.  In preparation for my CCIE R&S lab, I’ve been reading several different books.  The book today was CCIE Practical Studies Vol II by Karl Solie & Leah Lynch — an excellent resource for anyone wanting to sharpen their networking skills, and especially if going for the R&S CCIE!

The Question…

A question arose during the part of CTS that I wanted clarification, so I started digging around.  I wasn’t clear when using the shape average version of CTS, if the Be (aka excess-burst-size & excess-per-interval) was used, as all definitions I found was that the average method would only transmit up to Bc (CIR + Bc) per interval.  Nothing above.

What was confusing was that the Cisco documentation made no mention of not specifying the Be when using the average method.  Does the Be get used at all when using the shape average command form of CTS?  Based on their documentation (I’m using the 12.4 — see if for yourself at http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hqos_r/qos_s1h.htm#wp1085497), it appears that both the Bc and Be can be specified whether you’re using the average or peak method.

Ah, a moment of sanity — the answer revealed…

Both the book mentioned above and the Cisco documentation left me wondering if the Be was used with the average method, or if it was illegal to specify it (usually this is mentioned if so) or it’ll mess something up if it’s specified with average, etc.  I turned to another great book I’ve collected: IP Quality of Service by Srinivas  Vegesna.  According to this text, the Be value isn’t allowed at all with the average method — if it’s configured, it’ll be ignored (same as if Be was specified as 0).

After I read this, I tested it out on a 2811 running 12.4T and entered the following:

y(config)#policy-map test
y(config-pmap)#class class-default
y(config-pmap-c)#shape average 40000 1024 256
! no IOS complaint when this command was entered
y(config-pmap-c)#exit
y(config-pmap)#do sho run | b policy-map
policy-map test
class class-default
shape average 40303 30304 256
! okay, the IOS let the value stay in the config (didn't silently zero it out)
y(config-pmap)#exit
y(config)#exit
y#show policy-map test
Policy Map test
Class class-default
Traffic Shaping
Average Rate Traffic Shaping
CIR 40303 (bps) Max. Buffers Limit 1000 (Packets)
Bc 30304 Be 256
! again, the Be value shows up as I specified it above

If the text above is correct, even though the Be is specified, it’ll be ignored when the policy map is actually used.  I don’t have this router setup and am too lazy to try it out in the lab right now to double-check this hypothesis, but for now, I’m satisfied that I have an answer to my question above.