From: Andrew Bruce Caslow (abcaslow@netmasterclass.net)
Date: Thu Nov 23 2006 - 13:30:01 ART
Hi Alexei,
Let me attempt to help define this term "normal burst" value.
First, let me establish a point of reference. I am making the assumption
that we are discussing the "normal burst" value as it relates to the
Catalyst 3550 and Catalyst 3560 MQC police command. Let's take a quick peek
at where this term "normal burst" is used with the CAT 3550/3560 MQC police
command. After accessing both platforms in the NMC lab, I see that the sytax
is exactly the same on both platforms regarding the MQC police commannd.
Here are the configuration options I have found for the MQC police command:
c3(config-pmap-c)#police ?
<8000-1000000000> Bits per second
aggregate Choose aggregate policer for current class
c3(config-pmap-c)#police 8000 ?
<8000-1000000> Normal burst bytes
c3(config-pmap-c)#police 8000 8000 ?
exceed-action action when rate is exceeded
<cr>
Excluding the "police aggregate" option for now, I see that I have two
configuration options for the basic MQC police command:
Option #1: a mandatory bits per second rate. We will call this the "CIR".
Option #2: an optional "normal burst" value in bytes.
After this, there exists only one additional configuration option: the
"exceed-action" (see IOS output above). Consequently, there are not very
many configuration options with the Catalyst MQC police command. In
comparison to the MQC police command found on the routers, the CAT 3550/3560
switches have far fewer options. On the routers, I have CIR, PIR, BC and BE
options, including lots of different actions. Therefore, I have far fewer
options on the Catalyst 3550/3506 platform.
What do I derive from this examination of the MQC "police" command
configuration options? It is this: the MQC "police" command is a single-rate
two color policing mechanism. Like other single-rate two-color policing
mechanisms, it consists of the following two components:
1). A token replenishment rate called the CIR.
2). A Burst size. Let's call the Burst Size the "conformed" burst size. The
MQC police command on the CAT's is called a "normal burst". It can be called
a "conformed burst" or simply a plain old "burst". I suggest that you
disregard any special significance to the adjective "normal" in the "normal
burst" name found on the Catalyst 3550/3560 platform. It is simply the
single burst value associated with a standard single-rate two color policing
mechanism. This single "burst" parameter is also referred to as the size of
the token bucket.
Regarding the implementation of an "exceed burst" parameter with the
current CAT 3550/3560 MQC police command, there is no such parameter.
As with any single-rate two-color policer, there are two packet
classifications - (1) a conformed packet or "in-profile" classification and
a (2) exceed packet or "out-of-profile" classification.
A "conformed" packet classification is a packet whose length is less than or
equal to amount of tokens in the one and only one token-bucket used with the
MQC police command - the "normal burst" bucket.
A "exceed" packet classification is a packet whose length is greater than
the amount of tokens in the the one and only one token-bucket used with the
MQC police command - the "normal burst" bucket. While there may be an
"exceed packet classification" with the Catalyst 3550/3560 platform, there
is not "exceed burst" parameter.
I hope this is making some sense. I am certainly being long winded here. My
apologies in advance. I feel I need to define terms and concepts as I go. It
is the teacher in me!
When discussing either policing and/or shaping, I find it useful to frame
the discussion along the lines of two sub-discussions:
(1) Token replenishment for a shaper and policer
(2) Token consumption for a shaper and policer
Of these two sub-discussions, the first one - token replenishment - is a
predictable and deterministic process. The second one - token consumption -
is a more random process.
When discussing Token Replenishment for a shaper (I am going to limit my
discussion to the MQC shape peak and shape average command); the following
formula is involved CIR = Bc/Tc (Notice no reference to the Be parameter.)
When discussing Token Replenishment for a policer (I am going to limit my
discussion to the MQC police commands on both routers and CAT 3550/3560
switchs); the following two parameters are involved: CIR and
inter-packet-delay for all policers for both platforms; also the PIR for the
special case Two-Rate Three-Color-Marker on the Policer. (Notice no
reference to a Tc - a time measurement interval).
To better understand the function of token-replenishment of a policer and
the absence of the Tc parameter, it is useful to read the following two 3
page RFC's:
RFC 2697: A Single Rate Three Color Marker
RFC 2698: A Two Rate Three Color Marker
They are easy reads. You might need to re-read some paragraphs a few times
but they are only 3 pages long! Again, when you read them, you will see that
the role of the CIR is the role of token replenishment. The RFC's will state
that the associated bursts will receive a CIR worth of tokens per second.
Cisco (and other vendors) optimize this with an inter-packet delay
replenishment rate. Odom makes brief reference to this in his QoS book (very
good book!)
As a learning tool, we have developed a PERL script that will calculate the
inter-packet-delay token replenishment of a packet stream with a predictable
packet length and RTT. Such packet streams can be re-created with a simple
IOS ping command. It is a very insightful tool. We use it in our RS-NMC-1
class. The students love it. We are also going to use it in our upcoming QoS
Class-on-Demand/VoD Series.
In these QoS VoDs, we will be able to walk students through a progession of
multiple 3 router VoD mini-scenarios that clearly show how each of these
shapers and policers work. Once this progression of scenarios is in VoD
format, students will be able to watch them over and over again; and also
re-create the scenarios on their own routers. This is how we like to teach
at NMC - start with a little bit of theory and then make theory come alive
using the Cisco IOS. This results in many technical points being made, not
by mere discussion, but by: proof by IOS output - proof by show commands,
proof by debug traces, and many times for policing and shaping, proof by
ping packet patterns. We are working hard to get our classroom QoS
presentation in VoD format. It would be very useful and cheap!! We are
planning to release them at about $150.00. Please contact me off-line if you
think this is product you'd like to purchase.
If I can get my friends Bob Sinclair and Anthony Sequiera freed up to work
on these VoD's we can get them out to you more quickly. So much to do, so
little time. Wouldn't it be great to get Chris Lewis involved in discussing
Catalyst QoS in a Video on Demand series?! I'll contact him and ask him.
What the heck I will also ask his old study partners as well, Matt Leutjens
and James Matrisciano. As a group, these 3 CCIE's can create lots QoS VoD
content for the whole community. Wouldn't that be nice! If they need any
help, they can get help from the fastest VoD producer in the world - Mr
Anthony Sequiera! If anyone else wants to participate in creating these
VoD's, please contact me off line. The goal is to create lots of low cost,
modular CCIE-level modules from a wide range of content development sources
- like Chris Lewis, Bob Sinclair and Anthony Sequiera.
Sorry for the digression. In the meantime, this is a very large topic, if
the Group wants I can post some of these mini-scenarios into the GroupStudy
forum and you can review them. Over the year, students have found the
progression of these mini-scearios very useful. They help demystify many of
the points of confusion about QoS. All of these scenarios can be recreated
with 3-4 routers or 2 routers and 1 switch.
For starters, I normally start with the MQC shape average command on a
router. It will involve only three routers. From shape average, we go to
shape peak, all three router policers, and then into queuing and RED; and
then into CAT QoS. Students really enjoy the presentation. I will see if I
can get some help from Anthony and Chris on this little progression of
presentations.
I hope all is well. Happy Thanksgiving!
Best regards,
-Bruce Caslow CCIE #3139
NetMasterClass LLC
www.netmasterclass.net
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Alexei Monastyrnyi
> Sent: Thursday, November 23, 2006 8:41 AM
> To: Salman Abbas
> Cc: ccielab@groupstudy.com; petr@internetworkexpert.com; ivan@iip.net
> Subject: Re: 3550 QoS - Police problem
>
> Sounds right to me....
>
> Is the anyone who can shed some light on normal burst value?
>
> I remember reading that this is what we can allow above police rate,
> but can't find a source that easy.
>
> A.
>
> Salman Abbas wrote:
> > Hi Alexei,
> >
> > Thanks for the reply. Just to confirm whether I've correctly
> > understood u or not, Lets say the question says: maximum is 256kbps
> > and normal is 64Kbps, would that mean that I'll do
> >
> > Normal bytes = 256k - 64k = 192k => to bytes 24000, so the police
> > command would be
> >
> > police 64000 24000 exceed action drop
> >
> > Regards,
> >
> > Salman
> >
> >
> > On 11/23/06, *Alexei Monastyrnyi* <alexeim@orcsoftware.com
> > <mailto:alexeim@orcsoftware.com>> wrote:
> >
> > Hi.
> >
> > If I understand it right from DocCD, normal burst is what you have
> > above
> > the police rate. 256k-128k=128k => to bytes 16000/ If it should be
> > considered together with police rate, then just 256k=>32000 bytes.
> In
> > either case police rate should be 128000, not 256000 IMO.
> >
> > I would go for
> > police 128000 16000 exceed action drop
> >
> > HTH
> > a.
> >
> > Salman Abbas wrote:
> > > Hi guys,
> > >
> > > Pls help to answer the following question:
> > >
> > >
> > > On SW1 int fa0/6, limit all UDP traffic by maximum 256Kbps and
> > normal
> > > 128Kbps to avoid congestion on your VLAN.
> > >
> > >
> > > My solution is:
> > >
> > > mls qos
> > > access-list 101 permit udp any any
> > >
> > > class-map LIMIT
> > > match access-group 101
> > >
> > > policy-map POLICE
> > > class LIMIT
> > > police 256000 _____ exceed action drop
> > >
> > > int fa0/6
> > > service-policy input POLICE
> > >
> > > Now the part that I dont understand is that second value in the
> > police
> > > command which is "Burst in bytes". How can I calculate it based
> > on the
> > > question above? Also, am I missing anyting else in my
> configuration?
> > >
> > >
> > > Thanks in advance,
> > >
> > > Cheers!!!
> > >
> > > Salman
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART