From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Sat Mar 11 2006 - 11:47:56 GMT-3
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