From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Sat Sep 16 2006 - 14:14:02 ART
I see Pierre, glad we're on the same page now!
I think your problems are coming from your test methodology. If I read
correctly, your first policy looks like this
policy-map police
class class-default
police 64000 12000 conform-action transmit exceed-action
set-prec-transmit 1
This will not actually restrict the rate to the policed level in any way.
All it will do is transmit packets above 64K with precedence 1.
I would suggest two things. First apply this on a serial or ethernet
conenction to elimintae the cation of frame relay shaping just
to make things straightforward.
Then confirm that you have a test to drive the interface where you will
apply the policy to line rate.
The way I do this is to use a serial interface connected back to back and
set the clock rate to 512000.
Then you send 1400 byte ping packets with 0 timeout and repeat count 99999
Then with the load-interval set to 30 on the interface you should be able to
see how long it takes the interface
to show a throughput of 512000. Once you confirm your setup achieves line
rate before any policing
is applied and you know how long it takes the interface display to show
that.
If you can confirm you have a setup that meets the above and re-run the
tests, I think you'll see different results.
Chris
On 9/14/06, Pierre-Alex <paguanel@hotmail.com> wrote:
>
> Hi Chris,
>
> This mail is in reponse to a set of questions you asked that were never
> answered by the original poster. (Link bellow).
>
> I answered question 1- 4 easily, however with question 5 -experiments- I
> am getting too inacurate results.
>
> original post:
>
> http://www.groupstudy.com/archives/ccielab/200510/msg00518.html
>
> Your questions
>
> Question 1:
>
>
> 1. Policing does not queue packets, shaping does, if you have a policer and a
> > shaper configured for the same rate, will the shaper be able to queue packets?
>
>
> No obviously because the policier is "catching" the packets before the
> shaper.
>
>
> 2. Can you set actions based off rate for shaping? We know we can use the
> > presence or lack of BECNs to control the transmission rate between CIR and
> > mincir, but can you make arbitrary settings based on rate using shaping
> > commands?
>
> No options do to this with shaping options
>
>
>
> > 3. If you look at policing, can you set conditions for two rates using a single
> > token bucket? Can you use Bc or Be values to guarantee that a given action will
> > occur at a rate above the target policed rate for a single bucket system,
> > regardless of how traffic is presented to the policer? In other words, with a
> > single bucket system, can you constantly transmit at a rate above the policed
> > rate if you set Bc and Be to any value?
>
>
>
> If you have a single rate policier with two colors (single token bucket), then you define what will happen to traffic
>
> above the conform rate but you will not be able to specify a specific value.
>
> (The logic is "if everything is above x, then ....).
>
>
>
> If you have a single rate policier with three colors (two buckets), then you can set a burst, and decide what will
>
> happen above the conform rate and the burst. Unfortunately you will not be able to transmit continously at a given rate
>
> above the policed rate. In fact you will only be able to burst when you have transmitted less than the conform rate, and you
>
> have tokens that "spilled over" to the be be token bucket.
>
>
>
> 4. How does this change with a two rate (meaning two token bucket) system?
>
>
>
> With a two rate (two buckets, three colors), the be bucket is fed in parallele to the conform bucket, so you can have
>
> sustained transmission rate above the policed rate.
>
>
>
>
>
> 5. > Predict what will happen, and see if the results match your understanding by
> > looking at the show interface command with load-interval set to 30.
> >
> > police 64000 12000 conform-action transmit exceed-action set-prec-transmit 1
> > police 64000 12000 24000 conform-action transmit exceed-action
> > set-prec-transmit 1 violate-action drop
> >
> > Then try a two bucket system using the police cir xxx pir yyyy syntax and see
> > what you can come up with.
>
>
>
>
>
>
>
>
>
> Diagram:
>
> R2 is sending traffic to r5 fa0/1
>
> R2--e0/0--r4--ser0/0.405------ser0/0.504---r5--fa0/1
>
> R5 and R2 are clocked at 2 Mps
>
>
> Configuration:
>
> r4#sh run int ser 0/0.405
>
> interface Serial0/0.405 point-to-point
> ip address 10.4.5.4 255.255.255.0
> frame-relay class 405
> frame-relay interface-dlci 405
>
>
> r4#sh run | b map-class
>
> map-class frame-relay 405
> frame-relay cir 128000
> frame-relay mincir 128000
> service-policy output police_shape
>
>
>
> =============================
> Experiment 1
>
>
>
> r4#sh run | b policy-map
> policy-map police_shape
> class class-default
> police 64000 12000 conform-action transmit exceed-action set-prec-transmit 1
>
>
>
>
>
> In this policy we have a cir at 64 Kbps with a bucket of 96Kbytes.
>
> (12,000 bytes = 96 Kbps )
>
> I would expect the router to only be able to transmit up to 64Kbps of traffic with precedence zero, then another 64Kbps (up to traffic shapping rate) with precedence 1 .
>
>
>
> Results however show that I can only get to 107Kbps !!!!
>
>
> Why am I missing 21Kbps of traffic?
>
>
>
> r4#sh policy-map interface ser 0/0.405
> Serial0/0.405: DLCI 405 -
>
> Service-policy output: police_shape
>
> Class-map: class-default (match-any)
> 193316 packets, 20100289 bytes
> 30 second offered rate 695000 bps, drop rate 588000 bps
> Match: any
> police:
> cir 64000 bps, bc 12000 bytes
> conformed 17692 packets, 1837848 bytes; actions:
> transmit
> exceeded 175473 packets, 18248712 bytes; actions:
> set-prec-transmit 1
> conformed 63000 bps, exceed 631000 bps
>
> 107000 bps transmitted.
>
>
> ==================================
>
> Experiment 2
>
>
>
> r4#sh run | b policy-map
>
> policy-map police_shape
> class class-default
> police 64000 12000 24000 conform-action transmit exceed-action set-prec-transmit 1 violate-action drop
>
>
>
> In this policy with have a cir at 64Kbps with a conform bucket of 96Kbps and a burst bucket of double size (so we will get able to burst at 96Kbps over the 96Kbps conform bucket).
>
> I would NOT expect 64Kbps of traffic to be be trasnmitted at precedence zero and the rest up to te shapped rate of 128 at precedence 1 like in experiment 1, because we have a violate clause.
>
> If packets arrives very fast in the ser 0/0.405, I would expect all packets above the CIR to violate and therefore be dropped. Lets calculate : inbound on r4 e0/0 I have the following
> ( 5 minute input rate 774000 bits/sec, 852 packets/sec ). This corresponds to 96750 bytes per seconds. But the excess burst bucket is only filling at 24000 bytes per seconds. So I should be dropping everything.
>
>
>
> Results below show that I am only able to transmit 61Kbps of traffic : 695000-634000
> I am missing 3K of traffic, much less than experiment #1 though, and close enough to my estimate!??
>
>
> r4#sh policy-map interface ser 0/0.405
> Serial0/0.405: DLCI 405 -
>
> Service-policy output: police_shape
>
> Class-map: class-default (match-any)
> 1596662 packets, 166034525 bytes
> 30 second offered rate 695000 bps, drop rate 634000 bps
> Match: any
> police:
> cir 64000 bps, bc 12000 bytes, be 24000 bytes
> conformed 144900 packets, 15065000 bytes; actions:
> transmit
> exceeded 1112759 packets, 115723656 bytes; actions:
> set-prec-transmit 1
> violated 338473 packets, 35200272 bytes; actions:
> drop
> conformed 63000 bps, exceed 0 bps, violate 631000 bps
> r4#
>
>
> =====================================================
>
> Experiment 3
>
>
> r4#sh run | b policy-map
> policy-map police_shape
> class class-default
> police cir 64000 pir 192000
> conform-action transmit
> exceed-action set-prec-transmit 1
> violate-action drop
>
>
>
>
> Here I have set a cir to 64kbps and pir to 192kbps.
>
>
>
> I am expecting 64Kbps to be transmitted with precedence zero, then everything above up to 192Kbps to be transmitted with precedence 1, the rest to be dropped.Since my shapping is at 128Kbps, I would also expect some shapping to occur.
>
> Results show that I am only reaching 50000 kbps of conform traffic (14Kbps missing) , and 115Kbps of exeed traffic . Overall, I am only transmitting 106Kbps of traffic which does not meet my goal for 192Kbps!!! This transmition rate of 106Kbps actually corresponds closely to experiment 1. Can this be explained?
>
>
>
> r4#sh policy-map interface ser 0/0.405
> Serial0/0.405: DLCI 405 -
>
> Service-policy output: police_shape
>
> Class-map: class-default (match-any)
> 4208989 packets, 437697566 bytes
> 30 second offered rate 716000 bps, drop rate 610000 bps
> Match: any
> police:
> cir 64000 bps, bc 2000 bytes
> pir 192000 bps, be 6000 bytes
> conformed 375978 packets, 39094832 bytes; actions:
> transmit
> exceeded 1169702 packets, 121645728 bytes; actions:
> set-prec-transmit 1
> violated 2662056 packets, 276850524 bytes; actions:
> drop
> conformed 50000 bps, exceed 115000 bps, violate 548000 bps
> r4#sh run | b policy-map
>
>
>
>
>
> DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.405
>
> input pkts 480057 output pkts 480052 in bytes 49880578
> out bytes 49891011 dropped pkts 0 in pkts dropped 0
> out pkts dropped 1092892 out bytes dropped 113660548
> late-dropped out pkts 1092893 late-dropped out bytes 113660652
> in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
> out BECN pkts 0 in DE pkts 0 out DE pkts 0
> out bcast pkts 1288 out bcast bytes 109495
> 5 minute input rate 109000 bits/sec, 132 packets/sec
> 5 minute output rate 111000 bits/sec, 133 packets/sec
> pvc create time 01:32:21, last time pvc status changed 01:31:22
> cir 128000 bc 128000 be 0 byte limit 2000 interval 125
> mincir 128000 byte increment 2000 Adaptive Shaping none
> pkts 480088 bytes 49894755 pkts delayed 340424 bytes delayed 35389375
> shaping active
> traffic shaping drops 1092981
> service policy police_shape
> Serial0/0.405: DLCI 405 -
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:40 ART