From: simon hart (simon.hart@btinternet.com)
Date: Mon May 23 2005 - 05:53:28 GMT-3
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