QOS Shaping and queue | Class drops w/out congestion

Hi Guys,

I would like to ask what would be the cause of drops under a specific class (example q-crit) even there no congestion happening. Most of the traffic being match or used on this q-crit is TCP.

interface GigabitEthernet1/1 service-policy output shaping-out ! policy-map shaping-out class shape-v police 8000 conform-action drop exceed-action drop violate-action drop class shape-m police 8000 conform-action drop exceed-action drop violate-action drop class class-default shape average 10000000 service-policy output-queue ! policy-map output-queue class q-voip priority percent 35 class q-vid bandwidth remaining percent 36 random-detect dscp-based class q-crit bandwidth remaining percent 35 random-detect dscp-based class q-sig bandwidth remaining percent 9 class q-bulk bandwidth remaining percent 15 random-detect dscp-based class q-sger bandwidth remaining percent 1 random-detect dscp-based class class-default bandwidth remaining percent 4 random-detect dscp-based 

​

LOGS: Class-map: class-default (match-any) 281235753 packets, 169972732763 bytes 1 minute offered rate 2672000 bps, drop rate 3000 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/2811876/0 (pkts output/bytes output) 278376134/167782760950 shape (average) cir 10000000, bc 40000, be 40000 target shape rate 10000000 Overhead Accounting Enabled Service-policy : output-queue queue stats for all priority classes: Queueing queue limit 512 packets (queue depth/total drops/no-buffer drops) 0/14/0 (pkts output/bytes output) 6256268/1179379084 Class-map: q-crit (match-any) 124995944 packets, 116048365542 bytes 1 minute offered rate 866000 bps, drop rate 0000 bps Match: ip dscp af31 (26) af32 (28) af33 (30) Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/132908/0 <-- Drops (pkts output/bytes output) 124863036/115877406581 bandwidth remaining 35% Exp-weight-constant: 9 (1/512) Mean queue depth: 0 packets dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh prob af31 15254083/2341204955 43/5686 676/78391 28 32 1/10 af33 109608953/113536201626 4219/5874580 13456/18535019 20 32 1/10 Class-map: q-crit (match-any) 125203698 packets, 116222904682 bytes 1 minute offered rate 921000 bps, drop rate 0000 bps Match: ip dscp af31 (26) af32 (28) af33 (30) Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/132918/0 <-- Drops (pkts output/bytes output) 125070780/116051933227 bandwidth remaining 35% Exp-weight-constant: 9 (1/512) Mean queue depth: 0 packets dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh prob af31 15278539/2344989282 43/5686 676/78391 28 32 1/10 af33 109792241/113706943945 4229/5887074 13456/18535019 20 32 1/10 <--- DROPS INCREASING 

​

Question:

1. Please help me to understand the above "shaping-out" policy, So currently we are limiting approx. 10mb of data traffic and queue policy is applied also... Then so if congestion take place in outbound direction I still have 36% of 10m and 35% of 10m that will be allocated to class vid and voip for example..before droping the packets? Is the below computation is correct ?

Computation:

q-crit 35% = 3.5m will be allocated for queuing / q-voip 36% = 3.6m will be allocated for queuing .

1. Regarding the drops seeing on Q-crit is this due to microburst?

2. How can we possibly eliminate the drops at q-crit class and protect the data under this class?

3. Should we adjust the q-crit to properly tune this? What could be the advantages of it and effect to other queue class ?

​

Thanks in advance and hoping you can shed some light regarding the QOS method.