From: Sean C (Upp_and_Upp@hotmail.com)
Date: Mon May 23 2005 - 10:20:26 GMT-3
Simon - excellent findings!!!
I think I am in agreement with Simon on the points which he made 2 emails ago
on his email from 23 May 2005 09:53.
From Simon's posts, from the link on 12.1(5)T:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t
/121t5/dtpoli.htm#1028980
"In this particular example, traffic policing is configured with the average
rate at 8000 bits per second, the normal burst size at 2000 bytes, and the
excess burst size at 4000 bytes.
Router(config-pmap-c)# police 8000 2000 4000......"
So... since my last post, I guess the only discrepancy is what I found in the
2nd edition:
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'
Andy - just to be clear, I would recommend the latest and greatest Odom &
Cavanaugh book, which is titled 'Cisco QOS' and is the 2nd edition. The 1st
edition was titled 'Cisco DQOS'. Just want to make sure we're on the same
track.
Cool - I may actually understand and learn something here! When I'm following
the QoS posts, I usually feel like I'm watch a foreign language film w/out
subtitles.
Of course, this virtually guarantees I won't have any QoS on my next lab and
will find the lab to have an ATM/ISIS/multicast core with dlsw, IPv6 and
plenty of NAT!! ;-)
Thanks everyone! Sean
----- Original Message -----
From: "simon hart" <simon.hart@btinternet.com>
To: "simon hart" <simon.hart@btinternet.com>; "Sean C"
<Upp_and_Upp@hotmail.com>; "ccie zeng" <ccie.candidate@gmail.com>
Cc: <ccielab@groupstudy.com>; <ccie2be@nyc.rr.com>
Sent: Monday, May 23, 2005 6:38 AM
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
>
> _______________________________________________________________________
> 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.15 - Release Date: 22/05/2005
>
> _______________________________________________________________________
> 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.15 - Release Date: 22/05/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.15 - Release Date: 22/05/2005
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:00 GMT-3