From: Kay D (krsna83@gmail.com)
Date: Sun Jul 16 2006 - 12:41:19 ART
Hi ,
Still confused with whether "shape average " would allow excess
traffic if credits are available or does it send only in the first interval
. Please confirm and i can have a good sleep :)
TIA
Kay D
On 7/12/06, Montgomery, Jerry <jerry.montgomery@eds.com> wrote:
>
> Chris,
>
> Thanks for the link. The light bulb just came on!!!!
>
> Thanks.
>
>
> Respectfully,
> Jerry Montgomery, CCDP, CCNP, CCDA, & CCNA
>
> -----Original Message-----
> From: Chris Lewis [mailto:chrlewiscsco@gmail.com]
> Sent: Tuesday, July 11, 2006 2:13 PM
> To: Montgomery, Jerry
> Cc: Joe Gagznos; ccielab@groupstudy.com
> Subject: Re: Shaping Average / Peak vs. Policing
>
>
> Please read over the following:
>
> http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
>
> Shape peak does send Bc plus Be at every interval, contrary to my
> initial post.
> If things rae still unclear to you after reading this link, post again.
>
> Cheers
>
> Chris
>
>
> On 7/11/06, Montgomery, Jerry <jerry.montgomery@eds.com> wrote:
> Good morning, Chris,
>
> What is the main difference between shape average and shape peak?
>
> I am trying to answer the following scenario:
>
> Limit all traffic leaving FA0/0 with IP Precedence of 128K. Do not use
> policing or rate-limiting.
>
> Sometimes I convince myself that "shape average 128000 16000 0" is the
> answer (assuming Tc=125ms). And then sometimes I convince myself that
> "shape peak 128000" is the answer (default to Bc and Be).
>
> Any inside as to what the difference between "shape average" and "shape
> peak" are?
>
> Also, can you send me a link regarding Be being sent in addition to Bc
> on the first interval of a second only? I did not find that information
> explicitly stated.
>
> Thanks in advance.
>
> Respectfully,
>
> Jerry Montgomery
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Chris Lewis
> Sent: Wednesday, July 05, 2006 9:27 AM
> To: Joe Gagznos
> Cc: ccielab@groupstudy.com
> Subject: Re: Shaping Average / Peak vs. Policing
>
>
> Shape average does not allow Bc + Be to be sent every interval.
>
> Shape average allows Be to be sent in addition to Bc on the first
> interval of a second only, also the shaper needs to have built up credit
> in previous intervals to use Be. The effect of Be in shape average is to
> allow the shaper to achieve CIR over a long period of time,
> accommodating periods of lull where less than CIR is sent in one second,
>
> with an additional Be amount of data in a later period should the credit
> be available and the shaper needing to send more data.
>
> Chris
>
>
> On 7/4/06, Joe Gagznos < joegagznos@comcast.net> wrote:
> >
> > I am trying to find another way to limit outbound traffic through an
> > interface similar in manner to policing. I understand that
> > functionally the two are different. With shaping you are going to be
> > queuing excess traffic
> > to a predetermined rate where with policing you are going to be
> executing
> > some kind of action on traffic that exceeds the contract (usually
> > dropping).
> >
> > For comparison purposes, I have configured shaping and policing on two
>
> > separate subinterfaces in the following manner:
> >
> > interface Ethernet0/0.1
> > encapsulation dot1Q 10
> > ip address 10.1.1.1 255.255.255.0
> > service-policy output shape
> >
> > interface Ethernet0/0.2
> > encapsulation dot1Q 20
> > ip address 10.1.2.1 255.255.255.0
> > service-policy output police
> >
> > Both interfaces are configured to limit traffic to no more than 2.5
> > Mbps as
> > follows:
> >
> > policy-map police
> > class class-default
> > police 2500000 conform-action transmit exceed-action drop
> >
> > policy-map shape
> > class class-default
> > shape average 2500000
> >
> > What I find is that the shaping interface initializes the parameters
> > as
> > follows:
> >
> > R1#sh policy-map interface e0/0.1
> > Ethernet0/0.1
> >
> > Service-policy output: shape
> >
> > Class-map: class-default (match-any)
> > 19 packets, 1729 bytes
> > 5 minute offered rate 0 bps, drop rate 0 bps
> > Match: any
> > Traffic Shaping
> > Target/Average Byte Sustain
> > Excess Interval Increment
> > Rate Limit bits/int bits/int
> (ms)
> > (bytes)
> > 2500000/2500000 15000 60000 60000 24 7500
> >
> > Adapt Queue Packets Bytes Packets Bytes
> Shaping
> > Active Depth Delayed Delayed Active
> > - 0 19 1729 0 0 no
> >
> > A couple things to note here - Be is initialized to the same value as
> > Bc of 60000 (or 7500 bytes). The byte limit is 15000 bytes, though.
> > This must mean that the byte limit is initialized to Bc+Be=15000.
> > With a 24 ms interval, does this mean that the interface will send 5
> > Mbps (15000 * 8 bits
> > / byte * 1 sec/.024 = 5000000) instead of the contracted 2.5 Mbps?
> If
> > shape average is allowing the interface to transmit Bc+Be each
> interval,
> > then how does this differ from configuring shape peak which
> accomplishes
> > the
> > same thing?
> >
> > With policing it appears that things are much more straightforward.
> >
> > R1#sh policy-map int e0/0.2
> > Ethernet0/0.2
> >
> > Service-policy output: police
> >
> > Class-map: class-default (match-any)
> > 107 packets, 7473 bytes
> > 5 minute offered rate 0 bps, drop rate 0 bps
> > Match: any
> > police:
> > cir 2500000 bps, bc 78125 bytes
> > conformed 63 packets, 4305 bytes; actions:
> > transmit
> > exceeded 0 packets, 0 bytes; actions:
> > drop
> > conformed 0 bps, exceed 0 bps
> >
> > Thanks for any response!
> >
> > Joe Gagznos
> >
> > ______________________________________________________________________
>
> > _
> > 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 : Tue Aug 01 2006 - 07:13:47 ART