From: chrlewis@cisco.com
Date: Fri Sep 16 2005 - 12:51:04 GMT-3
Hello Stefan and Shun,
You have both asked similar questions, so I'm posting the two mails here
and trying to respond in one rather than 2 mails. I've also copied GS as
my last post had an error in it. If you're not interested in this topic
my apologies, this is a long post, but the delete button works just as
well :)
First of all I have to say I incorrectly commented on the Bc value for
policing and have provided a corrected response below. We have a new
baby in the house and I should probably not post until I get proper
rest!
I think a lot of the detail here will not help you explicitly on the
exam, but may make you more comfortable with the technology in general
(I hope :)
Anyway, dealing with the issue of the Bc and Be on police command first.
Both shaping and policing use a token bucket, which means traffic is
conforming or exceeding based of whether enough tokens are in the
bucket. However, one of the fundamental differences between shaping and
policing is that with shaping, tokens are added to the bucket at
pre-defined intervals, the Tc. This is not the case with policing. The
police method adds tokens as traffic arrives, so any concept of using Tc
to define policing behavior is meaningless to me, and that was my error
in responding to Stefan's post yesterday, I got shaping and policing
mixed up when calculating Tc. One does not calculate Tc for policing.
For policing, token replenishment is based upon [(T1-T) * target rate],
where T1 is the arrival time of the current packet and T is the arrival
time of the previous packet, the target rate is what you specify in the
police command. The token bucket is replenished on receipt of a packet
based on this formula and not based upon periodic (every Tc interval)
refresh. Looking at an example, we see how this operates.
If the target rate (CIR) is say 64kbps and the time elapsed between the
arrival of the current packet and last packet is say 250mS, then
T1-T = 250mSec
T1-T * CIR = 250 mSec * 64000 / 8 = 1000bytes will be used to replenish
the token bucket.
This happens with all subsequent packets. The amount of replenishment on
the receipt of each packet will be dependent upon the above formula.
What you are doing when you set Bc, is to set the depth of the token
bucket to which these tokens are added, once you reach the maximum
defined by Bc, no more tokens are let in until some have been taken out
by packet arrival.
Where does Be fit in? For CAR (the legacy rate-limit command) a single
token bucket for Bc and Be is used. In the example above, if the
replenishment of tokens did not leave enough tokens in the bucket, (and
here is where we start to leave the realms of applicable information),
it means tokens have to be borrowed from future allocation. One cannot
borrow tokens indefinitely, so the router keeps track with a value
called Debt (which splits in to actual and compound debt). But
basically, when compound debt is greater than Be, the packet is dropped.
Actual debt is the number of tokens borrowed by the current stream of
packets.
Compound debt = sum of all preceeding actual debt
Initially, the compounded debt = actual debt when you borrow tokens for
the first time.
This is simpler to understand with an example. Let's say you have three
packets come along and each needs to borrow 100 tokens in order to be
transmitted.
Actual debt = 100 after one packet, 200 after packet 2 and 300 after
packet 3. The compound debt at these stages are 100, 300, 600
respectively. The Compund debt is reset to 0 if a packet is dropped.
Actual debt is not forgiven after a packet drop. If actual debt is
greater than the Be value, all packets are dropped until actual debt is
reduced by the accumulation of tokens.
This is a simplified discusion, but even this I believe is unnecessary
for the exam, in terms of configuration, if you get in to thinking about
debt in the lab, you are off base IMO.
So what should you set the police burst parameters to? Well, the values
for Bc and Be in the police command really depend on the nature of your
traffic. For example, if your traffic stream is bursty and prone to
large intervals of silence and then a huge burst, it would probably be
best to configure a high extended burst value.
So for the exam, I would not configure Bc and Be for the police command
unless the question expressly required it. Something like saying burst
must be half the default, or something like that would trigger this
configuration in the question.
For single rate Class based policing as used in the MQC construct, Be
and Bc have separate buckets. In this case Bc sets the depth of the
confirm bucket and Be sets the depth of the exceed bucket. Excess tokens
from the Bc bucket flow over in to the Be bucket if new tokens arrive
that don't fit in the Bc bucket. Allocation of tokens is still driven by
packet arrival rather than the regular filling up as in the shaping
model. However, all this should be transparaent for what can actually be
tested under exam conditions. Unless the question expressly requires it,
leave the Bc and Be police values at the default. With a two rate MQC
configuration, the Bc and Be buckets are updated separately with each
arriving packet, based on the CIR or PIR value.
Now to the specific QoS question posted by Stefan. I think it is a bogus
question. It does not make sense to me. Either it comes from a poorly
wrritten workbook question (there are some on QoS out there believe it
or not), or IMO it is being mis-quoted from an actual exam. This topic
is confusing enough without dealing with questions that don't have
answers!
If the question related to a frame relay connection, I might interpret
the lower rate as the mincir value and the upper rate as the cir value,
this would allow the rate transmitted at to fluctuate between these two
values depending on the presence of BECNs (if the map-class is
configured with adaptive shaping), but on ethernet, I can't see what the
question wants you to achieve.
Now I'll try my best with a couple of Stefan's specific questions.
Stefan wrote:
4. I will ask another question about 3550 queuing. a) How we can limit
the input traffic some some rate say 64000. How we can limit input
traffic to 64000 and if the link is totally free and it is needed to
256000 also.
Probably I mixed up the police command for input and output traffic. But
as I ramember for output traffic we could do this for sure am I wright??
(ON the link about quos on 3550 I found just police (cir) (bc) )
[Chris replies] I can't work with the concept of transmitting at 64000,
then 256 at other times on ethernet, I don't know how to address that.
Either you target the transmit rate at 64 or 256k, I don't know how both
can be done at once. One can use the two rate policer to say transmit
below 64K, then mark differently between 64 and 256, then after 256
drop. On the 3550 for ingress policing you can classify on an ACL and
police the classified traffic. On egress, you can only classify on DSCP
for policing.
Stefan wrote:
5. As I thought about your suggestion about 2 rate policer. Did you mean
that?? :
police cir 64000 conform-action transmeed exceed-action transmeat pir
256000 conformation transmeet exceed-action drop
[Chris replies] You would configure a 2 rate policer to allow sub 64K
traffic, then mark between 64 and 256K ro DSCP 2, then drop above 256k
Like this
policy-map testpm2
class test
police cir 64000 pir 256000
conform-action transmit
exceed-action set-dscp-transmit 2
violate-action drop
Chris
-----Original Message-----
From: Stefan Grey [mailto:examplebrain@hotmail.com]
Sent: Friday, September 16, 2005 2:33 AM
To: Chris Lewis [chrlewis@cisco.com]
Subject: RE: Scenario 3550 + police problem. Help!!
Hello Chris,
Thanks, this info really helps. Here are some more my thoughts about
that.
1. The topology is not as you assumed. Switch and router are connected
by the ethernet direct link. One fa0/1 int of sw to fa0/0 int of the
router.
Fa0/1 is a routed interface. Ip routing is enabled on the switch and SW1
and Router can ping each other (very simple as directly connected
devices). Than in the question is just told that somewhere between them
is A server.
2. about my police command on the router. Sure your math is very
correct. It should be 1000 according to the Tc 125 ms. I forgot the
default number of TC and just typed in police 64000 command than typed
show policy-map command and it showed me the bc value 2000 thats why I
assumed that it should be so by default.
3. About max and normal rates you asked. I think it is so: The normal
rate should be 64000 and the traffic just can't exceed the 256000 (this
means in any case can't exceed but if the link is free and for some time
it can burst to the 256000). I think it is just as definition of the
police cir command on the router. If it is conf on Router as I did it
would send traffic in rate 64000 but if it's possible sometimes 256000
but not more). Am I wright?? Sorry I can't understand how two rate
policer would help here, probably you can explain??
4. I will ask another question about 3550 queuing. a) How we can limit
the input traffic some some rate say 64000. How we can limit input
traffic to 64000 and if the link is totally free and it is needed to
256000 also.
Probably I mixed up the police command for input and output traffic. But
as I ramember for output traffic we could do this for sure am I wright??
(ON the link about quos on 3550 I found just police (cir) (bc) )
5. As I thought about your suggestion about 2 rate policer. Did you mean
that?? :
police cir 64000 conform-action transmeed exceed-action transmeat pir
256000 conformation transmeet exceed-action drop
Regards,
From Shun:
Good Day !
After reading your below pasted lines, I have lost some clarity in my
understanding about policing.
"If you configure a 64000 rate with a Bc of 2000, that gives you a Tc of
1/4 not 1/8 by my math. It looks like you are trying to use Be to
provide the 256K maximum rate. I don't think this is feasible. Be is a
byte value, not a rate value and any attempt to make it so is
non-deterministic as it depends upon packet arrival rate"
Let me put it you in a simple way, if you were asked to configure a
policing with the rate of 64K, what would be the value of "bc" or "be"
over here? I may be confusing my self by comparing this police "bc" with
shaping "bc". I know shaping bc is nothing but the amount of data which
will be sent during the configured time interval(125ms default).But I
can't compare this with "bc" of policing?
As per Cisco, the below lines are the best practices to calculate bc,be
for
policing .
"Cisco recommends the following values for the Normal and Extended Burst
Parameters.
normal burst = r * 1byte/8bits * 1.5 seconds, where r is configured rate
extended burst = 2 * normal_burst
With the above choices for parameters, extensive tests results have
shown CAR to achieve the configured rate. If the burst values are too
low, then the achieved rate is often much lower than the configured rate
".
By looking at these things at one short, one will really go in a "?"
stage. Hence Can you clarify the points to revert from "?" stage to
"!!!" stage ?
1.The value of "bc" and "be" (in case of 3550, it is only bc) is derived
from what equation ? (I know theoretically they are value of bucket
depth etc..)
2. If one giving me only the policing bc and time interval (Tc) can I
calculate the actual rate which is used to calculate the bc in this case
? (in shaping , I can remember the relation with CIR= bc*1000/Tc
formula)
3. Is the Tc is fixed in the case of policing or will vary ? (Like in
your line pasted above, you have calculated it as 1/4 ....)
>From: chrlewis@cisco.com
>Reply-To: chrlewis@cisco.com
>To: "Stefan Grey" <examplebrain@hotmail.com>, <ccielab@groupstudy.com>
>Subject: RE: Scenario 3550 + police problem. Help!!
>Date: Thu, 15 Sep 2005 15:25:12 -0400
>
>There are a few things that don't seem right to me with the question as
>presented here.
>
>Assuming that the server and the router are on the same vlan, and
>connecetd to say fa0/1 and fa0/2 respectively on the switch.
>
>Taking the requirement, the server uses port 2000. Without being able
>to clarify this with a proctor, I would read this as there is an
>application on the server that responds to packets destined for port
>2000. That is packets going to the server has a destination port of
>2000.
>The terms max 256 and normal 64 do not mean anything to me in the
>context of QoS configuration. Any one else please offer an opinion.
>
>Looking at what you have configured (I think you meant to classify on
>port 2000, not 4000 :)
>
>Configuring police cir and just specifying the bc and be is the same as
>configuring it without the cir option, so I don't see the purpose.
>
>If you configure a 64000 rate with a Bc of 2000, that gives you a Tc of
>1/4 not 1/8 by my math. It looks like you are trying to use Be to
>provide the 256K maximum rate. I don't think this is feasible. Be is a
>byte value, not a rate value and any attempt to make it so is
>non-deterministic as it depends upon packet arrival rate.
>
>Typically if there are two rates specified in the question, it is
>looking for the two rate policer, specified with the police cir and pir
>command (you need to look on the 12.3 command reference for that).
>
>If you are told traffic comes from the router to the server via the
>switch, the question is doable. You can mark traffic destined for port
>2000 at ingress to the switch, then police based off internal DSCP on
>egress.
>
>There are however significant differences between the router police
>command and the switch police command. The 3550 does not support the
>two rate policer model, however the newer 3750 metro does, so that may
>open up more possibilities next year.
>
>I don't know if this helps, but the question does not make sense to me
>as presented.
>
>Chris
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Stefan Grey
>Sent: Thursday, September 15, 2005 12:05 PM
>To: ccielab@groupstudy.com
>Subject: Scenario 3550 + police problem. Help!!
>
>Hello group,
>
>I have got the tasK:
>The problem is with the Catalys configuration. Do Catalyst and Router
>have different police commands??
>
>TASK:
>
>SW1 - R6. Between this devices is a server which uses UDP port 2000. We
>should limit traffic so that max would be 256 Kbps and normal would be
>64 Kbps. Between SW1 and R1 is ethernet.
>
>END
>
>Please comment my solution. Suggest somethig. Why can't I complete
>this??
>
>My solution:
>We need to limit the input traffic so this should be policing (since as
>we know traffic shaping Is usually used for output traffic. So for R1
>the config would be:
>
>
>R6(config)#access-list 100 permit udp any eq 4000 any
>
>Is the access-list correct?? As I learned within my study eq should be
>on the side of the server. That's why any eq 4000 any.
>
>R6(config)#class-map match-all UDPCLASS R6(config-cmap)#match
>access-group 100 R6(config)#police-map UDPPOLICY R6(config-pmap)#CLASS
>UDPCLASS R6(config-pmap-c)#police cir 64000 bc 2000 be 24000 tc = 125
>so the parametrs are as above R6(config-if)#service-policy input
>UDPPOLICY R6(config-if)#
>
>NOW trying to do the same for the CAT1
>
>CAT1(config)#access-list 100 permit udp any eq 4000 any
>CAT1(config)#class-map match-all UDPCLASS CAT1(config-cmap)#match acc
>CAT1(config-cmap)#match access-group 100 CAT1(config-cmap)#exit
>CAT1(config)#poli CAT1(config)#policy-map UDPPOLICY
>CAT1(config-pmap)#class UDPCLASS CAT1(config-pmap-c)#poli
>CAT1(config-pmap-c)#police cir ?
>% Unrecognized command
>CAT1(config-pmap-c)#police cir ?
>% Unrecognized command
>
>
>CAT1(config-pmap-c)#police 64000 ?
> <8000-2000000> Normal burst bytes
>
>There is no police cir command. And the minimum normal burst is 8000
>and I can't set it to 2000.
>
>According to this I just don't know how to finish the task on SW1 and
>am mixed up with police commands. HOw different is policing on Catalyst
>and Router???
>
>Any comments are very appreciated.
>
>_________________________________________________________________
>Chat via voice, text or video - get MSN Messenger FREE!
>http://messenger.msn.co.uk
>
>_______________________________________________________________________
>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 : Sun Oct 02 2005 - 14:40:15 GMT-3