01-05-2010 04:16 AM - edited 03-01-2019 02:16 PM
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.
Solved! Go to Solution.
01-06-2010 05:59 PM
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.
01-05-2010 10:59 AM
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.
01-05-2010 11:52 PM
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.
01-06-2010 05:59 PM
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.
01-12-2010 07:04 AM
Thanks a lot for your explanation. I hope it will help me to develop proper configuration.
Best regards,
Andrei
01-02-2013 06:43 PM
Just wondering, how does the software calculate the value that will then be compared against the seperate finite value? Is there a formula?
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