From: Li Guoyi (Guoyi.Li@scs.com.sg)
Date: Thu Mar 29 2007 - 06:39:52 ART
Based on the syntax
Shape average cir
And
Shape peak cir
I still think "shape average 512000" send at 512000, as it sends at bc
"shape peak 512000" send at 1024000, as it sends at bc+be, be=bc here by
default.
But has anyone tested with real traffic and confirmed it?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
maureen schaar
Sent: Thursday, March 29, 2007 4:18 PM
To: Gary
Cc: Blastmor; Cisco certification
Subject: Re: shape average vs shape peak
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/hq
os_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