From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Sat Mar 11 2006 - 11:57:11 GMT-3
Thanks, Chris. I guess I was trying to use the ping to messure this. Thanks
for the clarification.
Dave
________________________________
From: Chris Lewis [mailto:chrlewiscsco@gmail.com]
Sent: Sat 3/11/2006 9:47 AM
To: Schulz, Dave
Cc: Popgeorgiev Nikolay; ccielab@groupstudy.com
Subject: Re: QoS policer, buckets, tokens
Not sure how you're calculating that. Ping is an indeterminate tool for
testing throughput, I would not try to use it for calculating accuracy of the
policer. I really do believe the policers and shapers are accurate now, a LOT
of internal testing validates that. The only way to really test the accuracy
is by something like a smartbits.
Chris
On 3/11/06, Schulz, Dave <DSchulz@dpsciences.com> wrote:
Chris -
I ran through your explanation in the lab, and it worked just as you
mentioned. However, I was just trying to do the math and am bit confused. I
am assuming that the ping of ping of a 450 bytes (equates to 3600 bps) and we
are experiencing a drop. Shouldn't we be able to transfer these without a
drop up to 16000 (bc of 128000/8). I think I am missing something on the math
here. Thanks for any clarification.
Dave
________________________________
From: nobody@groupstudy.com on behalf of Chris Lewis
Sent: Thu 3/9/2006 12: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 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
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, 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
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, 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
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, 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
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, 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
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, 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
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, 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
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, 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> 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]
> *Sent:* Thursday, March 09, 2006 5:00 PM
> *To:* Popgeorgiev Nikolay
> *Cc:* ccielab@groupstudy.com
> *Subject:* Re: QoS policer, buckets, tokens
>
>
> The previous post
> 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 <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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3