Understanding drops with a CBWFQ QoS service policy

Venison Mogambi · ‎04-03-2012

Hi,

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

Queueing

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?

Thanks.

paolo bevilacqua · ‎04-04-2012

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".

Joseph W. Doherty · ‎04-07-2012

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

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.

PS:

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.

Venison Mogambi · ‎05-02-2012

Hi,

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.