Traffic Shaping - drops

prasad.gsmc · ‎02-07-2009

Hi,

Please find the below output

Service-policy output: SHAPE_OUT

Class-map: class-default (match-any)

173428 packets, 57377408 bytes

5 minute offered rate 39000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 (packets)

(queue depth/total drops/no-buffer drops) 0/242/0

(pkts queued/bytes queued) 174048/57149759

shape (average) cir 256000, bc 1024, be 1024

target shape rate 256000

In that the BC and BE is set to 1024. Also one can observe that "total drops" are showing a value of 242.

I think this is a problem and we need to do some corrective action w.r.t BC value. Please help with your expert comments.

paolo bevilacqua · ‎02-07-2009

1024 is too small as Bc for a 256K CIR, as it involves a Tc of 4ms only. 10240 would be more reasonable.

Joseph W. Doherty · ‎02-07-2009

Shapers can drop packets when there's too much traffic. You have 242 drops across 173428 packets, which equals a cumulative drop percentage of (about) .14. This is offen acceptable. If these drops are due to transient congestion, you might be able reduce these drops by: increasing the queue depth, use peak shaping, or increase Bc (as Paolo suggests).

PS:

Paolo notes the Bc is setting a Tc of only 4 ms. I think I've noticed this now might be the default for the later 12.4 "T" software (previously default, I believe, usually was 25 ms). If it is a late 12.4T version (e.g. 12.4.2xT), I believe I've also noticed, what to me appears to be, a bug with shapers dropping traffic way below CIR rate (haven't reported it yet, but doesn't seem to behave that way if you back down a couple of T releases [i.e. at or before 12.4.15Tx]).

paolo bevilacqua · ‎02-08-2009

One also need to consider that Bc must make sense in terms of packet size.

Eg, 1024 only permit to send as burts a packet of 128 bytes, that's not very usueful. So keep Bc large enough to send one full packet if credit so allow.

Joseph W. Doherty · ‎02-08-2009

Excellant point! I believe I've read that recommendation too. Primary reason, I recall, something about the token bucket(s) would never have enough tokens to forward a packet larger than Bc. I would hope, though, if Cisco is now defaulting to a 4 ms Tc, that's this is no longer an issue. The low overall drop percentage, perhaps, might so indicate. If it doesn't, then you would want Bc to be large enough to handle largest packet size you might pass through the shaper.