QoS unanswered Mon, 10 Oct 2005 -

From: Pierre-Alex (paguanel@hotmail.com)
Date: Fri Sep 15 2006 - 01:17:46 ART


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
rateabove 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
havesustained 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-classmap-class frame-relay
405 frame-relay cir 128000 frame-relay mincir 128000 service-policy output
police_shape=============================Experiment 1r4#sh run | b
policy-mappolicy-map police_shape class class-default police 64000 12000
conform-action transmit exceed-action set-prec-transmit 1In 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
2r4#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 dropHere 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 bpsr4#sh run | b
policy-mapDLCI = 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