From: Popgeorgiev Nikolay (nikolay.popgeorgiev@siemens.com)
Date: Fri Mar 10 2006 - 04:57:14 GMT-3
Chris,
I think I found the idea, I made some tests with pings and now I can predict exactly which packed will be droped so you helped me a lot
thanks man
Nick.
_____
From: Chris Lewis [mailto:chrlewiscsco@gmail.com]
Sent: Thursday, March 09, 2006 7:45 PM
To: Popgeorgiev Nikolay
Cc: ccielab@groupstudy.com
Subject: Re: QoS policer, buckets, tokens
This is fairly easy to test, consider R1 connected to R2 over an HDLC link.
I configure inbound policing on R2 like this and R1 for a clocked rate of 512000
policy-map test
class class-default
police cir 128000 bc 1000
conform-action transmit
exceed-action drop
!
interface Serial0/1
ip address 10.1.1.2 <http://10.1.1.2> 255.255.255.0 <http://255.255.255.0>
service-policy input test
To start testing, R2 shows the following
R2(config-if)#do sho policy-map int
Serial0/1
Service-policy input: test
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
police:
cir 128000 bps, bc 1000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
I now ping from R1 with varying packet sizes
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 450
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 450-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
!!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!
Success rate is 76 percent (38/50), round-trip min/avg/max = 16/16/16 ms
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 950
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 950-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
!.!.!.!.!.!.!.!.!.!.!.
Success rate is 50 percent (11/22), round-trip min/avg/max = 32/32/32 ms
Now if I try with packet size 1001, nothing gets through
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]:
Datagram size [100]: 1001
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1001-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
.....
If I change the policy-map on R2 to the following
policy-map test
class class-default
police cir 128000 bc 2000
conform-action transmit
exceed-action drop
I get these results
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 950
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 950-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!!.!!
Success rate is 76 percent (38/50), round-trip min/avg/max = 32/32/32 ms
This is exactly the same success rate as with Bc equal to 1000 on R2, so you can see Bc does not affect sustained throughput.
Now however if I try one more test
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 2001
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 2001-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.
Success rate is 50 percent (25/50), round-trip min/avg/max = 64/64/64 ms
Packest above the Bc size are getting allowed, this is because the interfce MTU on so/1 is set to 1500 and they are fragmented.
If I change the clock rate to 64000 on R1, I get
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 950
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 950-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 240/241/244 ms
R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2 <http://10.1.1.2>
Repeat count [5]: 50
Datagram size [100]: 2001
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 2001-byte ICMP Echos to 10.1.1.2 <http://10.1.1.2> , timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 512/512/516 ms
So you have to look at the overall way the packet is delivered to see what will get through and what will not.
Chris
On 3/9/06, Popgeorgiev Nikolay <nikolay.popgeorgiev@siemens.com <mailto:nikolay.popgeorgiev@siemens.com> > wrote:
Ok thanks both of you I will real the previous post also
but Chris,
if a packet with size of 1500 bytes comes it can never never be served, no matter how much time has elapse after the previous packet used the tokens, cause the max bucket size can be 1000bytes right ?
And what matters how big I will make the bucket (Bc) when the average will be the same in the infinity ?
what is the difference in real situation between these two command:
police 128000 bc 1000
police 128000 bc 2000
thanks !
Nick
_____
From: Chris Lewis [mailto:chrlewiscsco@gmail.com <mailto:chrlewiscsco@gmail.com> ]
Sent: Thursday, March 09, 2006 5:00 PM
To: Popgeorgiev Nikolay
Cc: ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
Subject: Re: QoS policer, buckets, tokens
The previous post http://www.groupstudy.com/archives/ccielab/200509/msg00978.html <http://www.groupstudy.com/archives/ccielab/200509/msg00978.html> may help. Policing calculations are done as a packet arrives, the Bc defines the depth of teh token bucket, meaning if there are free toekns after the policing calculation done as a packet arrives, they will be put there for later use if needed. The CIR sets the rate that will be achieved on a continual basis.
In your case, the size of the packet is not inherently the issue. A packet will be forwarded if [t-t1]*CIR, where t is time of packet arrival and t1 is time of last packet arrival is greater than the number of bits to be transmitted, so it is more a case of the time between packets being offered for transmission as well as their size, rather than anything to do with their size as an isolated consideration.
Chris
On 3/9/06, Popgeorgiev Nikolay < <mailto:nikolay.popgeorgiev@siemens.com> nikolay.popgeorgiev@siemens.com> wrote:
Dear all,
After long and useless reading of all kinds of books, white papers, docCDs and other I can say that policing is still a mistery for me.
Please help.
I think I understand very clearly shaping and the idea of Bc, Be and tokens around it. But in policing it is a little different.
Let me tell you how I understand the things and tell me where my mistake is.
When I configure this command under policy-map
Police 128000 bc 1000 conform-acion transmit exceed-action drop,
As I understand the fundamentals a packet will be forwarded if:
- the packet is smaller than the Bc bucket or smaller than 1000 bytes in this case (otherwise fragmentation will be a good idea)
- enough time has elapsed after the previous packet was forwarded and the token bucket is filled enough to serve our packet
Other things I think are right
- if I have Bc=1000 this is my tocken bucket size and no matter how big the policed rate (in my case 128000) is, the tocken bucked cannot have more than 1000 tockens in it refilled?
Tha major thing I don't understand is If the above is right, what meaning does this policed rate has. What will be the difference if I put 256000 instead of 128000 ? Maybe the bucket will be refilled in smaller time with more tokens ?
And if I load the router with constant traffic let's say around 512 Kbit/s what output rate will be expected on the interface ?
You can see in what mess I am.
At least someone tell me if I am on the right path, and some more clarification about Policing will be very helpful.
Thanks,
Nick
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3