Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
You may experience some slow load times, errors, and slight inconsistencies. We ask for your patience as we finalize the launch. Thank you.

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Understanding drops with a CBWFQ QoS service policy


I applied a CBWFQ service policy to an IPSec/GRE tunnel interface, then did a show policy-map interface tunnel xxx to verify it was working. The different classes showed packets aggregating, so it seemed to be working okay, but I saw in the default class that it was showing queue drops. See the following output:

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

          33288729 packets, 21098403709 bytes

          5 minute offered rate 10693000 bps, drop rate 127000 bps

          Match: any


          queue limit 64 packets

         (queue depth/total drops/no-buffer drops/flowdrops) 0/210213/0/0

          (pkts output/bytes output) 33081023/23097596820

          bandwidth 25% (11250 kbps)

          Fair-queue: per-flow queue limit 16

            Exp-weight-constant: 4 (1/16)

            Mean queue depth: 7 packets

At the same time, when I do a show interface tunnel xxx, I don't see any drops:

router#sh int tunnel xxx

Tunnelxxx is up, line protocol is up

  Hardware is Tunnel

--output ommitted--

  Interface is unnumbered. Using address of Loopback0 (x.x.x.x)

  MTU 17868 bytes, BW 45000 Kbit/sec, DLY 50000 usec,

     reliability 255/255, txload 50/255, rxload 15/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source x.x.x.x, destination x.x.x.x

  Tunnel protocol/transport IPSEC/IP

  Tunnel TTL 255

  Tunnel transport MTU 4398 bytes

  Tunnel transmit bandwidth 8000 (kbps)

  Tunnel receive bandwidth 8000 (kbps)

  Tunnel protection via IPSec (profile "IPSEC_PROFILE")

  Last input never, output 24w6d, output hang never

  Last clearing of "show interface" counters 16:53:01

  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0

Any ideas as to why I'm seeing queue drops within the service-policy, but not on the inteface? Should I just increase the size of my default class?


  • Voice over IP
Hall of Fame Super Gold

Understanding drops with a CBWFQ QoS service policy

Drops happens because traffic is exceeding the allocated bandwidth.

Interface doesn't have to reflect these because they are not happing there.

Then for just another strangess, look "last output 24w".

Super Bronze

Understanding drops with a CBWFQ QoS service policy


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.


To expand upon what Paolo has already noted, policy drops should reflect on the interface the policy is applied to.  If you've applied the policy to the physical interface and not the tunnel interface, the tunnel interface stats will not reflect the policy drops.

As to why drops happen, as Paolo also notes, there's more traffic than the bandwidth will support.  Increasing queue limit can reduce drops if the traffic is only bursting above available bandwidth.


If the policy is on the physical interface, by default, it will see all GRE tunnel traffic as one flow.  I.e. unless you're sharing the interfaces with other flows, or shadow the original packet header, the policy is effectively global FIFO.

New Member

Understanding drops with a CBWFQ QoS service policy


Sorry for the late reply, but I had to travel and forgot all about this disussion. To follow up on my original question, this particular interface was a tunnel interface. I applied a QoS service-policy and was seeing drops in the default queue. I was confused because I couldn't see the drops on the tunnel interface, but I found the same drops on the physical interface. So you guys were correct.

Thanks for the feedback.