From: gladston@br.ibm.com
Date: Tue May 24 2005 - 17:57:56 GMT-3
Thanks Simon,
==============
we shall all get there very soon I
feel it!! :)
==============
It seems there is a light on the end of the tunnel :)
==============
Slight inconsistency here
==============
Yeah, when testing it this morning I saw you are right on yesterday post:
if not specifying violate action, it does not matter if Be is specified.
This example, from 12.2T config, shows that even though Be is configured
it does not show up on show policy. I am considering it is not used
because of this:
policy-map http-important
class http-imp
set dscp af21
police cir 64000 bc 8000 be 4000
conform-action transmit
exceed-action set-dscp-transmit default
Rack2R4#sh policy-map interface e 0/1
Ethernet0/1
Service-policy input: http-important
Class-map: http-imp (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url "*important*"
QoS Set
dscp af21
Packets marked 0
police:
cir 64000 bps, bc 8000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit default
conformed 0 bps, exceed 0 bps
if violate keyword is present, Be is used:
Rack2R4(config)#policy-map http-important
Rack2R4(config-pmap)# class http-imp
Rack2R4(config-pmap-c)# set dscp af21
Rack2R4(config-pmap-c)# police cir 64000 bc 8000 be 4000
Rack2R4(config-pmap-c-police)# conform-action transmit
Rack2R4(config-pmap-c-police)# exceed-action set-dscp-transmit default
Rack2R4(config-pmap-c-police)#violate-action dro
Rack2R4(config-pmap-c-police)#do sh polic int e0/1
Ethernet0/1
Service-policy input: http-important
Class-map: http-imp (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url "*important*"
QoS Set
dscp af21
Packets marked 0
police:
cir 64000 bps, bc 8000 bytes, be 4000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit default
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
About the PIR.
As per you said:
===========
CB with Violate action is a single rate three color marker
CB with a PIR statement becomes a two rate three color marker.
===========
And your quoted from Cisco:
================
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.
=================
I would summarize like this:
There are a bucket called Bc and a bucket called Be. If not specifying
violate, it does not use Be.
This statement is in accordance with 12.2T tests.
CAR has two-buckets without using the keyword violate. This is in
according with 12.2T tests and Wendell page 343.
CB is three color marker because it has three actions: conform, exceed,
and violate
CAR has only two actions.
This compares CB and CAR:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800d7276.shtml
If not configuring violate action, CB becomes single rate two color
marker, right? (only two actions)
It makes sense with the result of commands on the router.
If keyword PIR is specified, CB policing becomes two rate three color
marker (three color if Be is specified; there is no reason to specify PIR
and do not specify Be).
PIR is the rate at which the second bucket is replenished. Be is the size
of the bucket.
Interesting to compare Be bucket without and with PIR: without PIR, Be
depends on Bc tokens not used to fill Be. With PIR, Be is replenished
independently of Bc.
Results on 12.2T using PIR
Rack2R4(config-pmap-c)#police cir 64000 8000 pir 128000 be 16000
Rack2R4(config-pmap-c-police)#do sh run | be policy
policy-map http-important
class http-imp
set dscp af21
police cir 64000 bc 8000 pir 128000 be 16000
conform-action transmit
exceed-action set-dscp-transmit default
violate-action drop
Rack2R4(config-pmap-c-police)#do sh polic int e0/1
Ethernet0/1
Service-policy input: http-important
Class-map: http-imp (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url "*important*"
QoS Set
dscp af21
Packets marked 0
police:
cir 64000 bps, bc 8000 bytes
pir 128000 bps, be 16000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit default
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
Error on DQOS:
As you said, first edition, DQoS book says on page 391:
"To have no Be, you configure the burst-normal and burst-max values to the
same value."
It seems it is not true, as Sean pointed out.
Comparing CAR and CB policing without and with Be:
CAR
Without Be
Conform-> if there is enough tokens on bucket Bc
Exceed-> if there is no tokens on Bc
With Be
Conform-> if there is enough tokens on Bc or Be
Exceed-> if there is no tokens
Good to mention (but forget for CCIE Lab purpose) is that CAR with Be
algorithm is more complicated than CB policing algorithm. It uses Actual
Debt and Compounded Debt to discard some packets before use all tokens
from Be.
CB
Without violate (which is the same as saying without Be)
Conform-> if there is enough tokens on Bc
Exceed-> if there is no tokens
With violate
Conform-> if there is enough tokens on Bc
Exceed-> if there is enough tokens on Be
Violate-> if there is no tokens
PIR on CB policing does not change this actions, only defines a rate to
replenish Be.
Would you correct any point?
Thanks again for this great threat Simon, Sean, Caslow, Andy and Zeng.
Cordially,
------------------------------------------------------------------
Gladston
"simon hart" <simon.hart@btinternet.com>
24/05/2005 03:44
To
Alaerte Gladston Vidali/Brazil/IBM@IBMBR
cc
Subject
RE: RE: Bc and Be
Hi Gladston,
Slight inconsistency here - sorry but we shall all get there very soon I
feel it!! :)
Your first statements on CAR and CB are correct.
CB without Violate action does not truly mean single rate three color
marker.
If I do not specify a Violate action, and I specify a transmit action for
Be, then there is no ceiling to the policer.
CB with Violate action is a single rate three color marker
CB with a PIR statement becomes a two rate three color marker.
I know this is confusing, I shall try and get back to you with some
examples
Take care
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
gladston@br.ibm.com
Sent: 24 May 2005 00:38
To: ccielab@groupstudy.com
Subject: Re: RE: Bc and Be
Oh, thanks a lot, this discussion really went to the point.
It shades same light on more than one year doubts.
Unfortunatelly, as Simon said, it seems QoS is not coherent across IOS
versions.
Here is my summary:
CAR
Be must be greater than bc to have a value
CB
Be can be lower than bc to have a valid value
If not configuring violate-action, we are doing single rate-three color
marker (RFC 2697).
If configuring violate-action, we are doing Three Color Marker scheme with
two token buckets.
Shaping
Be can be of any value.
Any inconsistency here?
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:01 GMT-3