queue-limit

[Anukalp S]

Hi,

Seeing below logs it appears that class-default has 64 packets queue limit and per flow queue lenght is 16. Hence each queue would have 4 packets in buffer. Pls correct me if i am wrong.

Also pls tell me how could i avoid situation of packets being dropped in default queue. If i increase queue limit upto 300 then would i start getting slowness in applications.

Service-policy output: SHAPE

    Class-map: class-default (match-any)
      262672 packets, 189687263 bytes
      5 minute offered rate 6589000 bps, drop rate 21000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/526/0
      (pkts output/bytes output) 262405/190338657
      shape (average) cir 20000000, bc 80000, be 80000
      target shape rate 20000000

      Service-policy : police_voice

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 81/6162

        Class-map: VOIP (match-any)
          81 packets, 5520 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: access-group name voip
            81 packets, 5520 bytes
            5 minute rate 0 bps
          Match: ip dscp ef (46)
            0 packets, 0 bytes
            5 minute rate 0 bps
          Priority: 10% (2000 kbps), burst bytes 50000, b/w exceed drops: 0

        Class-map: class-default (match-any)
          262591 packets, 189681743 bytes
          5 minute offered rate 6589000 bps, drop rate 21000 bps
          Match: any
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 0/523/0/523
          (pkts output/bytes output) 262044/190080345
          bandwidth remaining 99% (17820 kbps)
          Fair-queue: per-flow queue limit 16

[Joseph W. Doherty]

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

If your per-flow limit is 16 how do you figure there only 4 packets in a buffer?

If there are 64 packets, all together, and 16 per flow queue, this, I believe, means there are only 4 dynamic egress queues.

Yes, you're correct, anytime you increase queue limits you may increase queuing latency.  However, you need to weigh that against premature queue drops for queue sizes too small.  Also realize, with FQ, one flow/application queuing isn't adverse to other flows, as is normally the case for global FIFO.

[Anukalp S]

Sorry Joseph for my wrong undersatnding on this. Yes there should be 4 dynamic queue as you said.

Actually i do not want users to face application slowness so is there workaround where drops rate can be minimize and no slowness as well.

[Joseph W. Doherty]

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

In theory, policing or WRED might be used.  The idea being you drops packets with incipient congestion and the some flow will slow their transmission rates.  (Of course, that too can lead to slowing an application.)  In practice, since most Cisco platforms don't support FRED, you experiment a bit with WFQ to find the optimal trade-off in queue depths vs. drops.

On "ordinary" network equipment, your tuning options are rather limited.  Some dedicated (3rd party) traffic shaping appliances can do much more.