04-03-2012 07:02 AM
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.
04-04-2012 04:40 AM
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".
04-07-2012 04:36 AM
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.
05-02-2012 08:02 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide