Total drops for class-map class-default

Question

Hi,
I have a gigabit ethernet interface on a 2951 configured with 4x sub interfaces providing connectivity to our four WAN sites. Each sub interface services a 100mb connection to another site.
I have configured a QoS policy and attached to each sub interface with the primary function of limiting each sub interface to 100mbs. I am now seeing drops (total drops) on the class default and not sure why. I would not expect to see any drops on this interface as it never even reaches 15mb (15%) capacity.
Any ideas?
        Class-map: class-default (match-any)
          175934881 packets, 95319007968 bytes
          5 minute offered rate 23000 bps, drop rate 0000 bps
          Match: any
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/340/0
          (pkts output/bytes output) 314212026/180287074028
policy-map PM-Branch-QoS
class CM-OAM
  set dscp af11
class CM-Network
  set dscp cs6
class CM-VC
  bandwidth percent 5
class CM-Citrix
  set dscp af21
class CM-CAPWAP
  set dscp af22
policy-map PM-WAN
class class-default
  shape peak 100000000
   service-policy PM-Branch-QoS

Answer 1

Disclaimer
The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.
Liability Disclaimer
In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.
Posting
I would not expect to see any drops on this interface as it never even reaches 15mb (15%) capacity.
Your expectations might be incorrect.  Often percentage of bandwidth capacity measurements are misunderstood.
Let's assume your ingress is 100 Mbps.  Let's also assume your measuring over a five minute period.  Lastly, assume the ingress transmits at 100% for 1 minute and then stops for 4 minutes.  Bandwidth utilization across the 1 minute would be 100% and 0% for the other 4 minutes, but it would be 20% for the 5 minutes.
But if the 100 Mbps was sent at 100% for each 12 seconds, and not sent for each 48 seconds, 5 minute utilization would still be 20% but unlike the prior 1 minute stats of 100% and 0%, each minute would now also be 20%.
So these first two examples show how bandwidth utilization don't reveal what's happening within the measured time period.
Since ingress was same bandwidth as egress, in the above, there would be no queuing.
If ingress is gig, though, suppose gig ingress arrives for 6 seconds and stops for a remaining 4 minutes and 54 seconds.  This too would measure as 20% usage across 5 minutes, but since it will take 60 seconds to transmit the same traffic at 100 Mbps, packets will need to be queued.  If queuing buffers are insufficient to hold all the packets, some will be dropped.
The above is a long way of saying, if your ingress rate exceeds your egress rate, there can be a need to queue packets, and if queuing is insufficient, packets will be dropped, this even if utilization is "low".  Most likely, you have occasional "bursts" if ingress bandwidth exceeds the egress bandwidth.
From your actual stats, the drop rate percentage is so low, you might not need to concern yourself with the few drops you're seeing.  If it is a concern, you might be able to reduce the drop rate by increasing egress buffering, but doing so, also increases egress queuing delay.