From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Fri Sep 15 2006 - 21:23:10 ART
Thanks for the followup Pierre, but I think you misread my intentions. I was
not asking the questions because I needed clarification, I knew the answers,
the intent was to ask questions of the person posting to make them think
about how things work.
Cheers
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