Re: shape average vs shape peak

From: maureen schaar (maureen.schaar@gmail.com)
Date: Thu Mar 29 2007 - 05:18:22 ART


I do believe shape peak can send no more that 512 Kbps and not 1024,
whereas shape average can send no more than 256 Kbps (but still the
counters in show policy map int disturb me).

The example you quoted from the doccd:
> bandwidth 300
> shape peak 512000

brings me to another issue regarding parent and child policy maps. If
you were to use this configuration with a bandwidth percent instead
of an absolute value, you would have to use a hierarchical policy-map
and the configuration above would not work. I have labbed it up and
put the results below.

Doccd reference:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part20/ch10/qsbcbts.htm#wp1046398

Quote/
If you want to use CBWFQ with the Class-Based Traffic Shaping
mechanism, the following conditions must be met:

A secondary-level (child) policy map must be created. This
secondary-level (child) policy map is then used to configure CBWFQ by
enabling the bandwidth command.

Traffic shaping must be configured in the primary-level (parent) policy map.

Note CBWFQ is supported in both the primary-level (parent) policy map
and the secondary-level (child) policy map. However, to use CBWFQ at
the secondary-level (child) policy map, traffic shaping must be
configured in the primary-level (parent) policy map.
/Unquote

Now the last note sounds like a contradiction to me with the first
bullet. If I want to use cbwfq and shaping, do I have to create a
parent and child policy? We will test what happens.

In that analogy, this configuration would be false:

policy-map SHAPE
 class class-default
 shape average 100000
 bandwidth percent 80 --> this is not 80% from the shaped rate, but
80% of the interface bandwidth

Now if I apply this policy-map, I get an error saying I am crossing
the max-reserved (75%) limit:
W2R5(config-if)#service-policy output PARENT
I/f Serial1/0 class class-default requested bandwidth 80%, available only 75%

This is pointing out that you are not using the shaped rate, but the
interface bandwidth.

So I changed the bandwidth percent to 60, to see what happened:

W2R5#sh policy-map int
 Serial1/0

  Service-policy output: PARENT

    Class-map: class-default (match-any)
      1 packets, 63 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)
           100000/100000 2000 8000 8000 80 1000

        Adapt Queue Packets Bytes Packets Bytes Shaping
        Active Depth Delayed Delayed Active
        - 0 1 63 0 0 no
      Queueing
        Output Queue: Conversation 41
        Bandwidth 60 (%)
        Bandwidth 76 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 1/63
        (depth/total drops/no-buffer drops) 0/0/0

--> NOTE: As I suspected: you are allocating 60% of the interface
bandwidth (12800) not of the shaped rate!

If I turn this into a parent/child situation, this happens:

policy-map child
 class class-default
 bandwidth percent 80 --> this is 80% from the shaped rate
policy-map SHAPE
 class class-default
 shape average 1000000
 service-policy child

W2R5#sh policy-map int
 Serial1/0

  Service-policy output: PARENT

    Class-map: class-default (match-any)
      25 packets, 721 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)
           100000/100000 2000 8000 8000 80 1000

        Adapt Queue Packets Bytes Packets Bytes Shaping
        Active Depth Delayed Delayed Active
        - 0 9 513 0 0 no

      Service-policy : child

        Class-map: class-default (match-any)
          25 packets, 721 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any
          Queueing
            Output Queue: Conversation 25
            Bandwidth 80 (%)
            Bandwidth 80 (kbps)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

Now I see that 80% of the shaped rate is allocated to the child policy-map.

FINAL QUESTION: does anyone think you have to use a hierarchical
policy-map also when using an absolute value for bandwidth? I still
don't quite get it with the mentioned contradiction in the doccd.

Thanks for all your help so far!

Maureen

On 3/29/07, Gary <liguoyi8@gmail.com> wrote:
>
>
>
>
> This link is from Cisco DocCD
>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hqos_r/qos_s1h.htm#wp1085303
>
> The following example uses peak rate shaping to ensure a bandwidth of 300
> kbps but allow throughput up to 512 kbps if enough bandwidth is available on
> the interface:
> bandwidth 300
>
>
> shape peak 512000
>
> If "shape peak 512000" is used, the throughput should be up to 2x512k =
> 1024k. So is it an error here?
> If in the lab, question asks to "allow throughput up to 512 kbps", which one
> is correct?
> shape average 512000
> or
> shape peak 512000?
>
>
>
> ________________________________
> From: Blastmor [mailto:alextols@gmail.com]
> Sent: Thursday, March 29, 2007 2:32 PM
> To: Gary
> Cc: maureen schaar; Cisco certification
> Subject: Re: shape average vs shape peak
>
>
> Shape peak is rather useless now.
>
> The case when you can use it, for instance, is when provider allows you to
> burst but you are warned that your traffic can be dropped at any time (when
> ISP is congested) --> so you can use it when your traffic is
> "steady" for jitter and losses(FTP, SMTP and so on)
>
> HTH
>
>
> 2007/3/29, Gary <liguoyi8@gmail.com>:
> > I am confused by average & peak too.
> > According to DocCD, the syntax is : shape peak cir
> > By default be=bc. So the target rate is two times cir.
> > So when should we use "shape peak" and when should we use "shape average"?
> >
> >
>
>
> SY, Alexey



This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART