From: Luis Rueda (userlerueda@hotmail.com)
Date: Fri Oct 07 2005 - 18:27:19 GMT-3
Ok,
What I'm trying to figure out is, what are you trying to do.
The real difference between shape average and shape peak is that with shape
average the router will send Bc bits each Tc interval, and with shape peak
the router sends Bc+Be bits every Tc interval. That being said, it means
that if you leave Bc and Be to the default values with shape peak you will
get twice the CIR. But that doesn't mean you don't have to tweak the Bc or
Be. If you are using this for Voice for instance, the Default values won't
be adecuate, you should instead look for the Bc to be 1/100 of the CIR in
order to obtain the Tc = 10ms, and the Be should be 0 cause any packets
going past the CIR may be dropped by your ISP. If those are voice packets,
voice may sounf choppy.
Regards,
Luis
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Dennis J. Hartmann
Sent: Friday, October 07, 2005 4:10 PM
To: 'Chris Lewis'; 'Bob Sinclair'; 'Thomwin Chen'; ccielab@groupstudy.com
Subject: RE: MQC-Based FRTS
Good conversation..... let's continue......
Now what we have to do is align this information with Best Practices /
Reccomendations for VoIP.
To follow the rules in the current QoS SRND www.cisco.com/go/srnd , we
need to set the (Tc) interval to 10ms. To do this, we would set the
committed bits per time interval to 640 (for a traffic rate of 64000).
Unfortunately, this is impossible because the interval must be in increments
of 128 and if you try to apply less than 1000 bits per interval to an
interface, the following error results:
Router(config-if)#service-policy output test less than 1000 bits in an
interval doesn't make sense
I re-configured the policy to "shape average 64000 1000 0". The
service-policy allowed me to apply this to the interface, but the Tc is now
15ms (close at least). This shouldn't be an issue for shaping above 100kbps
because the Bc would now be 1000 or greater to meet the desired 10ms Tc.
Router(config-if)#do show policy-map int Serial1/0
Service-policy output: test
Class-map: test (match-all)
0 packets, 0 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)
64000/64000 125 1000 0 15 125
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Cheers,
Dennis J. Hartmann
White Pine Communications
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
_____
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Friday, October 07, 2005 4:37 PM
To: Dennis J. Hartmann; 'Bob Sinclair'; 'Thomwin Chen';
ccielab@groupstudy.com
Subject: RE: MQC-Based FRTS
Dennis, you are correct that if you put in shape 64000, the output will be
shaped to 64000, and you do not need to specify the Bc and Be values. As the
IOS output shows from my previous mail, the software will pick a suitable Bc
value.
Where I do think it is worth further discussion how this technology works is
with the definition of Bc. Bc does not define any burst capability at all.
All Bc does is define the number of bits that will be sent each time
interval in order to reach CIR.
If you put in shape average 64000 or shape average 64000 16000, it makes no
difference to the shaped rate itself.
These two options represent a default Bc value of 8000 and 16000
respectively, you will end up with the same average throughput, just a
different number of bits put in the bucket at different time intervals.
This is illustrated in the show policy-map interface output given below:
A shape average 64000 entry in the policy-map gives a show policy-map
interface output of the following
Class-map: class-default (match-any)
2455 packets, 1765420 bytes
30 second 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)
64000/64000 2000 8000 8000 125 1000
A shape average 64000 16000 in the policy map gives the following sho
policy-map output
Class-map: class-default (match-any)
2455 packets, 1765420 bytes
30 second 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)
64000/64000 4000 16000 16000 250 2000
It is quite easy to show this has no effect on the shaped rate by entering
the following on the router with the policy-map on it
Router2#ping
Protocol [ip]:
Target IP address: 172.16.123.1
Repeat count [5]: 9999
Datagram size [100]: 1200
Timeout in seconds [2]: 0
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 9999, 1200-byte ICMP Echos to 172.16.123.1, timeout is 0 seconds:
Looking at the router interface at the remote end will show that it tracks
up to 63000 in each case, the extra 1K being lost to overhead.
I feel it would be more widely understaoofd if Bc was called committed bits
rather than committed burst.
Chris
"Dennis J. Hartmann" <dennisjhartmann@hotmail.com> wrote:
I have not played with the sustained bits per interval. I do know that
if you shape traffic to average w/o the sustained bits per interval, the
target and average rate in the show policy-map interface display the exact
same rate. This is different from early versions of IOS where the target
rate would be 1.5 times larger than the average rate because of the Bc.
The ONLY way to be 100% sure is to put a SmartBits packet generator
through the policy and I don't have access to one right now, but......
My understanding based on what I have seen is..... Shape average shapes
to CIR.
Sustained bits per interval in a shaping policy does point to Bc, so
"maybe" it's possible to enable Bc bursting by setting the number of bits
per interval.
Sincerely,
Dennis J. Hartmann
White Pine Communications
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
_____
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Friday, October 07, 2005 2:55 PM
To: Dennis J. Hartmann; 'Bob Sinclair'; 'Thomwin Chen';
ccielab@groupstudy.com
Subject: RE: MQC-Based FRTS
Dennis,
I think you overstate things a little in this reply.
Given that we are talking about shape average in an MQC policy-map, Bc and
Be are in fact still used in the same way that the legacy Bc and Be were in
the map-class configuration.
Looking at the following output from a router for the shape average command
Router2(config-pmap-c)#shape ?
adaptive Enable Traffic Shaping adaptation to BECN
average configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
send out Bc only per interval
fecn-adapt Enable Traffic Shaping reflection of FECN as BECN
fr-voice-adapt Enable rate adjustment depending on voice presence
max-buffers Set Maximum Buffer Limit
peak configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
send out Bc+Be per interval
The key thing to note is that if you type in shape average, you have the
option to put in additional values as shown in the following output:
Router2(config-pmap-c)#shape average 16000 ?
<256-154400000> bits per interval, sustained. Needs to be multiple of
128.
Recommend not to configure it, the algorithm will find
out
the best value
For sure you do not explicitly type in Bc, but if you type in a figure here,
it specifies the bits per interval that will be used to achieve CIR, which
is the definition of Bc. The formula CIR=Bc/Tc still holds for shape
average. So just as in the legacy map-class configuration, if you are told
to optimize to a given Tc value, you would configure a Bc value after shape
average 16000 to set the Tc.
I don't actually understand the term "shape average traffic to CIR + Bc" Bc
defines the number of bits transmitted per time interval to reach CIR.
As previously discussed, all shape peak does is allow Bc +Be to be
transmitted each time interval.
Chris
"Dennis J. Hartmann" wrote:
Bob: The Shape average command does not use either Bc or Be so
they're irrelevant. Shape average shapes traffic to CIR. Older version of
IOS (12.1) used to shape average traffic to CIR + Bc (even though IOS
documentation showed something different. 12.2 T code trains will shape
average traffic to CIR.
Where this does apply is with the Shape Peak command. The shape
peak command uses both Bc and Be using the formula "average rate (CIR) * Bc
/ Be". Since Bc and Be default to 8000, the formula is CIR * 2 which
results in twice the effective bandwidth over time (assuming wire rate
traffic at CIR * 2.
-Dennis Hartmann
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Bob
Sinclair
Sent: Wednesday, June 15, 2005 1:23 PM
To: Thomwin Chen; ccielab@groupstudy.com
Subject: Re: MQC-Based FRTS
Thomwin,
No, do not configure the command "frame-relay traffic-shaping" when doing
MQC-based shaping. When doing MQC-based shaping remember that the "shape
average" command automatically sets Be equal to Bc, so set Be explictly to 0
if the task does not require an excess burst. Also remember that if you
want to shape at the DLCI level, using a map-class frame-relay, then you
must shape class class-default.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: Thomwin Chen
To: ccielab@groupstudy.com
Sent: Wednesday, June 15, 2005 1:02 PM
Subject: MQC-Based FRTS
Hi All,
just want to confirm.
to configure MQC-Based FRTS, should I use frame-relay traffic-shaping
command in main interface ?
In CiscoDoc, MQC-Based FRTS don't have frame-relay traffic-shaping command
in main interface ??
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12
2t/122t13/frqosmqc.htm
thanks
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3