From: Pierre-Alex (paguanel@hotmail.com)
Date: Sat Sep 16 2006 - 03:24:46 ART
Chris, I have no doubt you knew the answer.
I think everyone around knows you are a QoS Guru!!!
I wrote the answers just to make a contribution to the board - the questions
where quite good and made me think! (thanks)
On this point, would you mind looking at question number 5? I do not
understand why the experiment results are so much off.
Pierre
----- Original Message -----
From: Chris Lewis
To: Pierre-Alex
Cc: ccielab@groupstudy.com
Sent: Saturday, September 16, 2006 2:23 AM
Subject: Re: QoS unanswered Mon, 10 Oct 2005 -
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 willhappen 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 youhave 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/1R2--e0/0--r4--ser0/0.405------ser0/0.504---r5--fa0/1R5 and R2 are clocked
at 2 MpsConfiguration:r4#sh run int ser 0/0.405interface Serial0/0.405
point-to-point ip address
10.4.5.4 255.255.255.0 frame-relay class 405 frame-relay interface-dlci
405r4#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-mappolicy-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 bps107000 bps
transmitted.==================================Experiment 2 r4#sh run | b
policy-mappolicy-map police_shape
class class-defaultpolice 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 bpsr4#=====================================================
Experiment 3r4#sh run | b policy-mappolicy-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