Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Total drops for class-map class-default

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

1 REPLY
Super Bronze

Re: Total drops for class-map class-default

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.

220
Views
0
Helpful
1
Replies
CreatePlease to create content