7609 ES20 Default Queue Limit

Answered Question
Jan 5th, 2010
User Badges:

Hello.


Could anyone provide me with a link to documentation, describing how a default queue limit for a particular class is calculated on a ES20-GE3C linecard.

The same policy map applied to interfaces with configured BWs of 1 Gbit/s and 4 Mbit/s produces limits of 16590 and 66 packets respectively for a class with a bandwidth reservation of 40%. I would like to get better understanding of how this was calculated.


Thank you in advance.

Correct Answer by Laurent Aubert about 7 years 2 months ago

Andrei,


1- Forget the queue-limit for the parent policy. It's irrelevant and not used at all. Only the queue-limit of the child policy are used.

2- If you statically configure a queue-limit, this is actually the value used. If you let the router calculated it you could see a different value without traffic and with traffic (Hw updated it when receiving traffic).

3- WRED will work as expected.


Increasing the queue-limit of a class will decrease the chance of drop but will increase the delay and latency for this class.


HTH


Laurent.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Laurent Aubert Tue, 01/05/2010 - 10:59
User Badges:
  • Cisco Employee,

Hi Andrei,


The software will calculate a value based on the allocated bw but hw implements only some finite values so the closest finite value to the calculated one will be chosen (will always be the value smaller than the calculated one).


The finite values are: { 330290, 132110, 66050, 49780,  33025, 16590, 6635, 3315, 1655, 660, 330, 66}


HTH


Laurent.

vialikasielec Tue, 01/05/2010 - 23:52
User Badges:

Thank you very much for response. I would like to ask you one more question which actually forced me into all this research


I have a rather simple case: tiered policy map with parent policy for shaping and child policy for CBWFQ and WRED. This looks like this:


router#sh policy-map shape-4m


  Policy Map shape-4m
      Description: Shapes traffic to 4 Mbit/s average
    Class class-default
      Average Rate Traffic Shaping
      cir 4000000 (bps)
      service-policy qOUT


router#sh policy-map qOUT   

  Policy Map qOUT
    Class gold
     police cir percent 40 be 0
       conform-action transmit
       exceed-action drop
       violate-action drop
      priority
      queue-limit 800 packets
    Class silver
      bandwidth 40 (%)
       packet-based wred, exponential weight 9
      random-detect dscp-based aggregate
      random-detect dscp values 24 minimum-thresh 700 maximum-thresh 800 mark-prob 1
      queue-limit 800 packets
    Class bronze
      bandwidth 4 (%)
       packet-based wred, exponential weight 9
      random-detect dscp-based aggregate
      random-detect dscp values 48 minimum-thresh 70 maximum-thresh 90 mark-prob 1
      queue-limit 90 packets
    Class scavenger
      bandwidth 1 (%)
    Class class-default
      bandwidth 10 (%)
       packet-based wred, exponential weight 9
      random-detect dscp-based aggregate
      random-detect dscp values 0 minimum-thresh 170 maximum-thresh 200 mark-prob 1
      queue-limit 200 packets


And when applied to interface:


router#sh policy-map int gi 1/0/0 out

GigabitEthernet1/0/0

  Service-policy output: shape-4m

  Counters last updated 00:00:06 ago

    Class-map: class-default (match-any)
      28356958 packets, 3559173107 bytes
      30 second offered rate 950000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 66 packets
      (queue depth/total drops/no-buffer drops) 0/2967/0
      (pkts output/bytes output) 28344273/3554046799
      shape (average) cir 4000000, bc 16000, be 16000
      target shape rate 4000000

      Service-policy : qOUT

      Counters last updated 00:00:06 ago

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

        Class-map: gold (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: mpls experimental topmost 4  5
          Match: ip dscp cs4 (32) af41 (34) ef (46)
          Match: ip precedence 4  5
          police:
              cir 40 %
              cir 1600000 bps, bc 50000 bytes, be 50000 bytes
            conformed 0 packets, 0 bytes; actions:
              transmit
            exceeded 0 packets, 0 bytes; actions:
              drop
            violated 0 packets, 0 bytes; actions:
              drop
            conformed 0 bps, exceed 0 bps, violate 0 bps
          Priority: Strict, b/w exceed drops: 0
         
         

        Class-map: silver (match-any)
          26153885 packets, 2785205707 bytes
          30 second offered rate 925000 bps, drop rate 0 bps
          Match: mpls experimental topmost 2  3
          Match: ip dscp af21 (18) cs3 (24) af31 (26)
          Match: ip precedence 2  3
          Queueing
          queue limit 800 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 26144433/2784293418
          bandwidth 40% (1600 kbps)
            Exp-weight-constant: 0 (1/1)
            Mean queue depth: 0
            dscp    Minimum Maximum  Mark
                       thresh  thresh  prob
            default           16      33  1/1
            24               700     800  1/1
         

        Class-map: bronze (match-any)
         
          377475 packets, 529477768 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: mpls experimental topmost 6
          Match: ip dscp cs6 (48)
          Match: ip precedence 6
          Queueing
          queue limit 90 packets
          (queue depth/total drops/no-buffer drops) 0/2967/0
          (pkts output/bytes output) 374508/525292903
          bandwidth 4% (160 kbps)
            Exp-weight-constant: 0 (1/1)
            Mean queue depth: 0
            dscp    Minimum Maximum  Mark
                       thresh  thresh  prob
            default           16      33  1/1
            48                70      90  1/1
         

        Class-map: scavenger (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: mpls experimental topmost 1
          Match: ip dscp cs1 (8)
          Match: ip precedence 1
          Queueing
          queue limit 66 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 1% (40 kbps)

        Class-map: class-default (match-any)
          1825598 packets, 244489632 bytes
          30 second offered rate 23000 bps, drop rate 0 bps
          Match: any
          Queueing
          queue limit 200 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1825332/244460478
          bandwidth 10% (400 kbps)
            Exp-weight-constant: 0 (1/1)
            Mean queue depth: 0
            dscp    Minimum Maximum  Mark
                       thresh  thresh  prob
            default           16      33  1/1
            0                170     200  1/1


As you can see I have tuned queue limits for every traffic class within child policy manually. However it remains the same for parent policy (66 packets) and can not be changed. I would like to know how these queues are related to each other. What happens to arriving packets when shaping is in action? Do they go into the queue with 66 packets limit and get dropped when this limit is exceeded? Or are they classified and placed in the appropriate queue with its own manually set limit? Does WRED work in this situation? My colleague noticed that drop count is equal for parent policy and for bronze class so child policy seems to be working but i would like to get any kind of confirmation from you. Any links to related documentation would be appreciated.

Correct Answer
Laurent Aubert Wed, 01/06/2010 - 17:59
User Badges:
  • Cisco Employee,

Andrei,


1- Forget the queue-limit for the parent policy. It's irrelevant and not used at all. Only the queue-limit of the child policy are used.

2- If you statically configure a queue-limit, this is actually the value used. If you let the router calculated it you could see a different value without traffic and with traffic (Hw updated it when receiving traffic).

3- WRED will work as expected.


Increasing the queue-limit of a class will decrease the chance of drop but will increase the delay and latency for this class.


HTH


Laurent.

vialikasielec Tue, 01/12/2010 - 07:04
User Badges:

Thanks a lot for your explanation. I hope it will help me to develop proper configuration.


Best regards,

Andrei

Carl Andress Wed, 01/02/2013 - 18:43
User Badges:

Just wondering, how does the software calculate the value that will then be compared against the seperate finite value? Is there a formula?

Actions

This Discussion