# Task 10.44 Two Rate Three Color Policer

in QoS

Solution uses Be of 6400 while the task says to use PIR*200ms for Be which is 3200.

Any idea why? Looks like the solution is correct and the task is wrongly worded?!

• I agree.  Either the solution should be 'police cir 64000 bc 6400 pir 128000 be 3200' or the task should be reworded as 'Use the values of CIR*200ms and PIR*400ms for normal and excess burst sizes.'

• SEconded, I had to read the task a few times to realize that the wording was a little ambigious.

This feels like a lab workbook semantics issue and I couldnt imagine that problem on the real lab.

• Hi null_route,

I don't agree with you. I think that the Be bucket & Bc bucket MUST be filled at the same time but in the same interval, I mean the Tc. Because Tc is just the silence between the incoming packets come from same interface.

Be = 6400 bytes, PIR = 128kbps => Tc = Be/PIR = 6400*8/128000 = 0.4s

Bc = 3200 bytes, CIR = 64kbps => Tc = Bc/CIR = 3200*8/64000 = 0.4s

Be bucket is refilled at PIR rate, during the Tc amount of time

Bc bucket is refilled at CIR rate, during the Tc amount of time as well

So, I think the correct statement is:

" Use the values of CIR*400ms and PIR*400ms for normal and excess burst sizes "

• This task got me confused as well.

The way I understand it, there is no concept of Tc like there is in shaping when it comes to policers.

RFC2698 describes in detail how the token buckets are emptied and replenished. The token buckets are replenished by the CIR or PIR rate times the difference in packet arrival time, bounded by either Be or Bc (depending on which bucket you're looking at).

To do this in real-time at high packet rates would be impractical and too taxing on the router's cpu. Therefore the Cisco implementation of RFC2698 uses an internal scheduling interval at which point in time the calculations are done. This policer granularity effectively calculates an average and thereby determines the precision with which the router can police traffic.

I found this reference to a conversation between Joe Astorino and Petr Lapukhov that talks about this:

http://groups.jonzu.com/z_cisco_policing-and-cirpirbcbe.html

From reading INE WB I's explanation of this task, it looks like this scheduling interval is the same for the Be and Bc bucket calculation. Therefore I would venture to say that the workbook task should have read " Use the values of CIR*400ms and PIR*400ms for normal and excess burst sizes ", as rockerptit pointed out.

Could someone from INE please confirm that this is correct?

I also configured a policer and let ios determine what the Be and Bc values should be, suggested that the IOS scheduling interval is 250ms:

R1(config)#policy-map 2rTCP

R1(config-pmap)#class class-default

R1(config-pmap-c)#police cir 64000 pir 128000

R1(config-pmap-c-police)#conform-action transmit

R1(config-pmap-c-police)#exceed-action set-dscp-transmit cs3

R1(config-pmap-c-police)#exit

R1(config-pmap-c)#

R1#sh policy-map

Policy Map 2rTCP

Class class-default

police cir 64000 bc 2000 pir 128000 be 4000

conform-action transmit

exceed-action set-dscp-transmit cs3

violate-action drop

R1#

2000*8*4=64kbps , 4000*8*4=128kbps.

So my question is: does setting the be and bc values affect the scheduling interval for the policer at all and if so, how ?

Many thanks,

Marcel

• I must say this has me stumped to!

I'd hazard a guess that as "a special timer fires every Ti interval and triggers a token refresh" that the Ti value for both Be and Bc needs to be equivalent.

As such, I'd be inclined to agree with rockerptit that both Tc values should be 400ms such that the question reads:

"Use the values of CIR*400ms and PIR*400ms for normal and excess burst sizes.

Over to you INE... fancy jumping in and proving one of us right or wrong? [:D]

• Can anyone clear this up? Is this a workbook typo? Or is there an explanation for the be vlaue of 6400