08-21-2018 10:06 AM - edited 03-08-2019 03:57 PM
Hi team,
I have configured the policing as below
policy-map Rate_limit
class Ratelimit
police 1500000 1000 conform-action transmit exceed-action drop
If i go with the formula of CIR (cir=bc/tc), the value of CIR is 1509433 , which is coming more than what i have configured. Since this is more, i would like to know whether the excess bandwidth gets policed here ?
Added to this i would like to know will there by any issues if the Bc value is allocated more.
Regards,
VJ
Solved! Go to Solution.
08-22-2018 02:30 AM - edited 08-22-2018 02:32 AM
Your Tc of 5.3(333..) ms is correct (Tc = Bc/CIR), but unsure how that "implies" CIR = 1509433. I.e. what "extra" 9433 bits? Remember you've configured CIR and Bc, it's Tc that's derived, not CIR.
If there are more than 8000 bits seen during the Tc, excess should be dropped. Where things get a bit messy, in a datagram network, data is sent in frames/packets, so it's a whole frame/packet that's dropped. I recall (also mentioned by Georg) somewhere Cisco does recommend insuring your policing parameters are such that a single max size frame/packet won't exceed policing. (NB: later IOS versions might protect against that. [BTW, generally, I configure the CIR and allow the IOS to default the Bc. With policing it's very easy to be overly aggressive and preclude any flow bursting {providing an effective transfer rate much lower than expected/configured}. I.e. it's best to have a Bc that mimics an interface queue of some depth. Also BTW, Cisco's Be and/or PIR would be very nice, if implemented as some Cisco documentation says it should work, but I've found often it's just Bc+Be without carrying forward credit for unused Bc/Be.])
08-21-2018 02:45 PM
Hello,
how do you come up with a CIR value of 1509433 ? Policing doesn't use tc.
Basically, the first value is that value of the rate at which you want to police (in bits per second). The second value is the size of the token bucket (in bytes per second).
A token bucket of 1000 will cause almost all traffic to be dropped, since most Ethernet frames are 1500 bytes, so the token bucket in your case will always be full.
Can you clarify what you are asking ?
08-21-2018 11:57 PM
CIR is calculated by the formula Bc/Tc
So in my case Bc=1000bytes = 8000bits and Tc =5.3 ms , implies, CIR = 1509433
If i configure police to 1500000 with Bc 1000 bytes, it means that during the period of 5.3ms , i can send no more than 8000 bits of traffic
So per second i will be having around 188 intervals, with each interval carrying 8000bits of traffic.
In this my question is i have configured the conform rate of 1500000, and if i go by calculation it is leading to 1509433. So the extra number 9433 bits will be chopped or will it considered as an extra tokens in the bucket.
08-22-2018 01:29 AM
Hello,
the tc is actually 5.3333333333333, that is where your difference comes from. But as I said it doesn;t matter, because policing doesn't use tc. You can test this with applying your policer to an interface with a tc of 1000, and send regular 1500 byte pings. None will go through, because the bucket is too small.
08-27-2018 09:21 AM
Yep, you are right, i had forgotten the decimal (0.3333) to consider.
08-22-2018 02:30 AM - edited 08-22-2018 02:32 AM
Your Tc of 5.3(333..) ms is correct (Tc = Bc/CIR), but unsure how that "implies" CIR = 1509433. I.e. what "extra" 9433 bits? Remember you've configured CIR and Bc, it's Tc that's derived, not CIR.
If there are more than 8000 bits seen during the Tc, excess should be dropped. Where things get a bit messy, in a datagram network, data is sent in frames/packets, so it's a whole frame/packet that's dropped. I recall (also mentioned by Georg) somewhere Cisco does recommend insuring your policing parameters are such that a single max size frame/packet won't exceed policing. (NB: later IOS versions might protect against that. [BTW, generally, I configure the CIR and allow the IOS to default the Bc. With policing it's very easy to be overly aggressive and preclude any flow bursting {providing an effective transfer rate much lower than expected/configured}. I.e. it's best to have a Bc that mimics an interface queue of some depth. Also BTW, Cisco's Be and/or PIR would be very nice, if implemented as some Cisco documentation says it should work, but I've found often it's just Bc+Be without carrying forward credit for unused Bc/Be.])
08-22-2018 04:17 AM
The diffference is simply the dropped 3s:
8000/1500000 = 0,005333333333333
0,0053 x 1500000 = 7950
0,005333333333333 x 1500000 = 8000
What I meant with 'no tc' is that policing uses tc in a different way than e.g. shaping. That is why I mentioned the example of configuring the lowest possible bucket size, 1000, which causes all packets (assuming the standard size of 1500) to fail.
At least that is how I understand it...
08-22-2018 05:32 AM
08-22-2018 02:01 AM
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