From: Michael Zuo (mzuo@ixiacom.com)
Date: Tue Sep 19 2006 - 21:00:16 ART
Hi Nick,
Thanks for the tip. Is there a "show" I can use to verify that this is
case?
thanks
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nick Davey
Sent: Wednesday, September 13, 2006 9:46 PM
To: ccielab@groupstudy.com
Subject: Re: Traffic Policing
David,
If that was configured with the rate-limit command you would not have a
be
as be includes bc.
with the police command you have a be of 8000. Therefore with the
rate-limit
command a be of 0 is when the bc and be value is the same and with the
police command a be >0 means u have some sort of be.
I think the police command used to work the same as the rate-limit
command
regarding be up to some variant of IOS 12.2 and thus the confusion. I
got
caught by this in my first attempt.
Hope this helps.
Nick.
On 9/14/06, David Redfern (AU) <David.Redfern@didata.com.au> wrote:
>
> Hi Guys,
>
> Just wondering if anyone can clarify the below question. I've found
> documention confusing on this one.
> The below policing has a rate of 64000, bc of 8000 and be of 8000.
>
>
> policy-map test
> class class-default
> police 64000 8000 8000
>
>
>
> Is the 8000 be IN ADDITION to the 8000 bc of is it the peak,
effectively
> meaning 0 excess burst?
>
> In other words does this mean they can burst up to 128000K or not
burst
> at all?
>
> If I want to be able to burst an additional 8000 bytes above my
confirm
> burst do I use 8000 or 16000 for my be?
>
>
> Any help would be appreciated?
>
>
>
>
>
>
>
>
************************************************************************
*****
> *
> - NOTICE FROM DIMENSION DATA AUSTRALIA
> This message is confidential, and may contain proprietary or legally
> privileged information. If you have received this email in error,
please
> notify the sender and delete it immediately.
>
> Internet communications are not secure. You should scan this message
and
> any
> attachments for viruses. Under no circumstances do we accept
liability
> for
> any loss or damage which may result from your receipt of this message
or
> any
> attachments.
>
>
************************************************************************
*****
> *
>
>
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:41 ART