From: simon hart (simon.hart@btinternet.com)
Date: Mon May 23 2005 - 15:41:10 GMT-3
Bruce,
Your comments are invaluable (as usual). Rest assured that although I have
been spending a great deal of time sifting through the written resources
available on this subject, I have been testing on my own suite of routers.
In fact it is interesting to note that the show commands for CB policing are
somewhat different between router platform and IOS (for example between
12.2(7) and 12.2(15) ), this I must say only helps to add to the confusion.
On your last paragraph I note that you say that to have a burst of zero,
then do not enter a value for Be. I notice that if I do this on my 12.2(7)
2500's then the IOS adds a value of Be that is equivalent to Bc. As the IOS
creates a default action of drop to this Be, I assume that this is just the
same as having no burst.
Policy Map qos
Class http
police 8000 2000 2000 conform-action transmit exceed-action drop
Incidentally on a 2600 running IOS 12.2(15), the show command is somewhat
different
Policy Map NEWQ
Class ICMP
police cir 8000 bc 1000
conform-action transmit
exceed-action drop
I also note that if I make the exceed-action a transit or set statement, but
without entering a violate action, then there really is no ceiling to the
burst, thus the value of Be is insignificant. Traffic will go through at
line rate.
Thanks again for taking the time on this
Kind Regards
Simon Hart
-----Original Message-----
From: Andrew B. Caslow [mailto:abcaslow@netmasterclass.net]
Sent: 23 May 2005 15:22
To: 'simon hart'; ccielab@groupstudy.com
Subject: RE: Bc and Be
Simon, Peng and Sean,
I think it is great you are all doing your research through reading.
However, take your research beyond simply what books tell you and even other
people tell you. Do not perform your research by simply "quoting scripture".
You always should include in your research the following: accessing a router
or switch and entering in commands related to the topic. Once, you have done
this, enable the appropriate debugs and enter relevant show commands.
I have glanced at this QoS thread, and correct me if I am wrong, but I
haven't seen any analysis and research based on going to a router and
entering in the CAR rate-limit command and the CB-Police command. Has this
been performed? If it has been, what have you learned from this.
Let's put the textbooks and RFC's down for a second and go to a router.
First, let's enter in the following CAR command:
R1(config-subif)#rate-limit in access-group 101 8000 10000 2000 con tr e dr
Illegal extended burst size
Increasing extended burst size to 10000
In the configuration above, 8000 = CIR, 10000=Conformed Burst, 2000=Extended
Burst.
I have entered in a Extended Burst that is LESS THAN the conformed
burst...AND I received the following error message:
Illegal extended burst size
Increasing extended burst size to 10000
This tells me I can never have an extended burst size less than the
conformed burst size. Therefore, if I don't want any Excess burst at all, I
CANNOT ENTER IN 0 FOR AN EXTENDED BURST. This is further supported by my
options for setting the Extended Burst value, which the IOS CLI help calls
the "Maximum Burst". I have come to the conclusion that I cannot enter in a
value of 0 for a CAR Extended Burst.
R1(config-subif)#rate-limit in access-group 101 8000 10000 ?
<2000-1024000000> Maximum burst bytes
I perform these steps on a router, and then I read an authoritative textbook
(I quote some scripture! :) ). On p. 44 in the "IP Quality of Service" book
by Vegena (Cisco Press), he states: with CAR, no extended burst capability
is available when Bc = Be.... with CAR, Extended Burst capabilities are
available only when Be > Bc.
I think we are in agreement with this statement.
Now, let's approach what I believe is the central issue of Simon's original
question: "with the CB-police command, is it true that an Extended Burst is
available only when the Be value is greater than the Bc value, just like
CAR?".
The answer to this question is no. With the CB-Police command, an extended
burst is available when the Be is less than Bc. When you configure the Be
value with the CB-Police command, you enable a single rate-three color
marker (RFC 2697). You create two separate and distinct token buckets: a
Conformed Burst Bucket and an Exceed Burst Bucket. The conformed burst
bucket gets replenished first. The Exceed Burst bucket only gets replenished
when the Conformed Burst bucket is fully replenished.
OK, let's see what options the router gives us related to the CB-Police
command:
R1(config-pmap-c-police)#pol 8000 16000 1000
Notice that it took the command with a Be less than Bc while the CAR
configuration did not. Now, when I look at the configuration options for
both Bc and Be I notice neither of them have non-zero value.
R1(config-pmap-c)#pol 8000 bc ?
<1000-512000000> Burst bytes
conform-action action when rate is less than conform burst
pir Peak Information Rate
<cr>
R1(config-pmap-c)#pol 8000 bc 16000 be ?
<1000-512000000> Burst bytes
conform-action action when rate is less than conform burst
pir Peak Information Rate
<cr>
How do I eliminate the ability to generate an Excess Burst with a CB-Police
configuration? How do I set Be to zero? Answer: you simply do not set the Be
at all.
Remember one of the significant differences between CAR and CB-Policing. CAR
does not have a violate-action. It has only a conform and exceed action.
Only CB-Police has the violate action. The CB-Police command implements the
Three Color Marker scheme with two token buckets. One bucket for
conform-bursts and the second bucket for exceed burst. If a packet cannot
obtain tokens from either of these buckets, it is in a violate state. CAR
does not operate in this manner.
I am terribly sorry. I need to cut this e-mail short. I have got to go right
now. Work beckons.
I hope these comments are of help.
-Bruce
Th
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Monday, May 23, 2005 6:39 AM
To: simon hart; Sean C; ccie zeng
Cc: ccielab@groupstudy.com; ccie2be@nyc.rr.com
Subject: RE: Bc and Be
I have now determined the following, that maybe of assistance to some (and
probably not others).
The Police command under MQC was first introduced in 12.0(5)XE. The manner
by which this algorithm works appears to conform with the Policing section
in Wendell Odoms DQOS Version 1 book (ISBN# 1-58720-058-9) and is very
similar to the operation of CAR.
The Police command uses a different algorithm from 12.1(5)T onwards and
supercedes that of 12.0(5)XE, and seems to broadly conform with RFC 2697 -
SRTCM.
Wendell Odoms' subsequent publication (ISBN# 1-58720-124-0) refers to this
algorithm.
I have added both links to these features for your reference. On a couple
of reads they do make sense.
12.0(5)XE
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
limit/120xe/120xe5/mqc/mqcfm/police.htm
12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121
t/121t5/dtpoli.htm#1028980
A very brief comparison on CAR and CB policing
http://www.cisco.com/warp/public/105/cbpcar.html
Lastly a link that relates to rfc 2698 TRTCM. There has been lots of
discussion in the past on PIR and its function. This document will go
somewhere to overcoming that particular hurdle
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
t/122t4/ft2rtplc.htm
HTH
Simon
Isn't QOS fun !! :)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
simon hart
Sent: 23 May 2005 09:53
To: Sean C; ccie zeng; Andrew B. Caslow
Cc: ccielab@groupstudy.com; ccie2be@nyc.rr.com
Subject: RE: Bc and Be
Sean and Bruce,
This has somewhat confused me, but I think I maybe gaining some clarity.
I have the Wendell Odom DQOS book, 1st edition, which I have been using as
my reference (as well as the CCO literature etc.)
In version 1 it clearly states the following in relation to CB policing on
pg391
'The police command configures CB policing inside a policy map. On the
police command, you define the policing rate in bps, the busrt-normal in
bytes, and the burst-max in bytes. Note that although Bc is represented by
burst normal in the command, the configured burst-max value is actually
Bc+Be. To have no Be of x, configure the burst-max parameter to a value of
x more than burst normal.'
Now from what you have described in Version 2 of Wendell's book, and Bruces
comments earlier it seems that the statement above is incorrect. In fact
closer inspection of the DocCd on the Police command shows the statement and
much of the CB policing material in Version 1 of Wendell Odom's book to be
obselete.
Quote from DocCd
'The Traffic Policing feature works with a token bucket algorithm. Two types
of token bucket algorithms are in Cisco IOS Release 12.1(5)T: a single-token
bucket algorithm and a two-token bucket algorithm. A single-token bucket
system is used when the violate-action option is not specified, and a
two-token bucket system is used when the violate-action option is specified.
'
>From what I can tell from the DocCd, unless I enter violate-action then
there will be no burst (be) allowed, and that packets will only conform up
to Bucket Bc.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
_r/qrfcmd5.htm#wp1064737
This does seem to be quite misleading, as the IOS does allow one to enter
the Be on the command line, for example
Policy Map qos
Class http
police cir 1000000 bc 2000 be 4000
conform-action transmit
exceed-action drop
But upon inspection of the interface that this policy resides upon we can
see, that the Be has not been applied:
Class-map: http (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
police:
cir 1000000 bps, bc 2000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Therefore to summarise my understanding now:
1. Replace Wendell Odoms version 1 of Dqos with Version 2 :0 ........
immediately
2. When using CAR - then Bc+Be = extended Burst
3. For CB policing, if one does not use the violate-action command, then
the policer defaults to the single token bucket philosophy, and Be has no
impact upon the command. If packets conform to Bc they will take the
conform action, and if they do not conform to Bc they will take the exceed
action. No bursting into Be here - at all.
4. If the violate action command is entered, then be becomes an active
component and the policer changes (as if by magic) to a Two token bucket
algorithm. Now if Bc is empty and a packet arrives, Be is checked and an
exceed action taken if enough tokens are left in Be or the violate action if
not taken. In this situation, the configured Be value is 'literal', meaning
that it is a not a function of Bc + Be as the case with CAR (and Wendell's
V1 book).
And Finally........... In answer to Zeng's original question I believe the
following would be configured
1. CAR
rate-limit output 1000000 1000 2000 conform-action transmit exceed-action
drop
2. CB Policing
Police 10000 bc 1000 be 1000 conform-action transmit exceed-action transmit
violate-action drop
Any comments on glaring errors would be gratefully recieved
Thanks
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Sean C
Sent: 22 May 2005 20:18
To: ccie zeng; Andrew B. Caslow
Cc: simon hart; ccielab@groupstudy.com
Subject: Re: Bc and Be
Hi Zeng,
I believe you are looking at the DQOS book - ISBN# 1-58720-058-9
Bruce is referring to the new QoS book - ISDN# 1-58720-124-0
Both books are authored by Odom and Cavanaugh. The book Bruce is referring
to is the 2nd edition of the book you are referencing.
Please note - in the 1st edition & the 2nd edition - both books use the same
example
1st edition - pg393
2nd edition - pg387
-all traffic policed at 96kbps
-Bc of 1 second's worth of traffic allowed
-Be of 0.5 second's worth of traffic is allowed
-traffic that violates is dropped
-traffic that exceeds the contract is marked down to DSCP Be
-traffic that conforms to the contract is forwarded with no re-marking.
but the solutions and accompanying explanation are not the same:
1st edition (pg 393-4):
police cir 96000 bc 12000 be 18000.......
"The excess burst configuration parameter actually defines the Bc and Be
value combined, in bytes. So, the value is configured at 18000, which is
6000 bytes more than Bc."
2nd edition (pg 388-9:)
police cir 96000 bc 12000 be 6000....
"The excess-burst configuration parameter is 6000 bytes, or half of Bc."
To further complicate the issue - in the 2nd edition, the 1st sentence on pg
389 actually looks like if was copy and pasted from the 1st edition by
stating 'police cir 96000 bc 12000 be 18000...' even though the example on
pg 388 uses 'be 6000'
Interestingly, the 1st edition's errata does not address this. And it does
not appear there is an errata for the 2nd edition yet.
HTH (if it doesn't confuse you),
Sean
----- Original Message -----
From: "ccie zeng" <ccie.candidate@gmail.com>
To: "Andrew B. Caslow" <abcaslow@netmasterclass.net>
Cc: "simon hart" <simon.hart@btinternet.com>; <ccielab@groupstudy.com>
Sent: Sunday, May 22, 2005 2:48 PM
Subject: Re: Bc and Be
> Hi Andrew:
> according to pg,393 in DQOS book, it says all traffic is policed at
> 96kbps,
> Bc of 1 seconds worth of traffic is allowed(12000bytes), Be of 0.5
> seconds worth of traffic is allowed(6000bytes), Then when you look at
> the configuration at next page, you will see it configure be as 18000,
> not 6000.
>
> Did I misunderstood your statement?
> Thanks
> Zeng
>
>
> On 5/22/05, Andrew B. Caslow <abcaslow@netmasterclass.net> wrote:
>> Simon,
>>
>> Regarding the CB-police command, the Bc and Be create two separate and
>> distinct token buckets. You can have a Be that is equal to or even less
>> than
>> the Bc and you will still be able to have an excess burst. This is
>> central
>> to the operation of the single-rate three-color-marker. If you have the
>> Wendell Odom book, check out pages pp 388-393. He has a couple of
>> examples
>> where Be is set to a value less than Bc. Odom also has a nice summary on
>> CB-Police parameters on pp. 405-406.
>>
>> I hope all is well.
>>
>> -Bruce
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>> simon hart
>> Sent: Sunday, May 22, 2005 4:40 AM
>> To: ccie zeng; Cisco certification
>> Subject: RE: Bc and Be
>>
>> Zeng,
>>
>> You are right. If you configure both bc and be to the same value there
>> is
>> no extended burst. In order to achieve your stated goal, then bc 1000
>> and
>> be 2000 would be correct.
>>
>> Be careful when using these police commands, I would recommend that you
>> always use the ? prompt to determine whether you need to enter bits or
>> bytes.
>>
>> Also the relationship between bc and be is different when using Traffic
>> shaping. When traffic shaping any value of be will be the absolute value
>> of
>> the burst.
>>
>> HTH
>>
>> Simon
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>> ccie zeng
>> Sent: 22 May 2005 09:30
>> To: Cisco certification
>> Subject: Bc and Be
>>
>>
>> Hi:
>> Could anyone clarify to me, when I asked to configure normal burst
>> size 1000 bytes, and excess burst size 1000 bytes for CAR or CB
>> policing, should I configure like this ".....bc 1000 be 2000" or just
>> "...bc 1000 be 1000".
>>
>> Based on my understanding if Be is configured as 1000, then there is
>> no excess burst, is that right?
>>
>> Thanks
>> Zeng
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005
>>
>> _______________________________________________________________________
>> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:00 GMT-3