From: Scott Morris (swm@emanon.com)
Date: Fri Feb 27 2004 - 14:05:37 GMT-3
Heheeheh... I have never pretended to understand the logic of an IOS
programmer. :) perhaps because it is a fleeting concept!
Scott
-----Original Message-----
From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
Sent: Friday, February 27, 2004 11:53 AM
To: Scott Morris; Brian McGahan; Michael Snyder; ccielab@groupstudy.com
Subject: RE: interplay between mqc bandwidth percent and
max-reserved-bandwidth?
Hi Scott,
actually the way I'm reading this note is that it changed again and that as
of IOS 12.2T/12.3 we're back to reservations relative to the link bandwidth,
not the 'available bandwidth', while we gained a new command, 'bandwidth
remaining percent', to make reservations relative to the 'available
bandwidth'.
It seems like the people coding these IOS features can't really make up
their mind :)
Regards,
Tom Lijnse
CCIE #11031
Global Knowledge Netherlands
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Friday, February 27, 2004 3:52 PM
To: Tom Lijnse; 'Brian McGahan'; 'Michael Snyder'; ccielab@groupstudy.com
Subject: RE: interplay between mqc bandwidth percent and
max-reserved-bandwidth?
You are not misreading the tech note. In the early implementations (12.0
into 12.1) everything was based off of the total link bandwidth. And the
maximum you could reserve was 75% (if you did more, the device complained).
People got confused by this, so it changed.
Now, it all references the "available bandwidth" which is real bandwidth *
75% (by default). You can always check this out in 'show interfaces'.
Don't forget that any of your "priority" stuff through LLQ or IP RTP
Priority will be deducted just the same pool of available bandwidth.
I'm not entirely sure this is a "more logical" approach, but... I don't
make the rules. :) But you are reading the document correct, and the
behavior HAS indeed changed over the releases.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tom
Lijnse
Sent: Friday, February 27, 2004 3:02 AM
To: Brian McGahan; Michael Snyder; ccielab@groupstudy.com
Subject: RE: interplay between mqc bandwidth percent and
max-reserved-bandwidth?
Hi Brian,
Thanks for your answer. I have an additional question though. In your reply
you state that there's no difference in the way the 'bandwidth percent'
command works for the different IOS versions. According to you "The MQC is
always based on this available bandwidth value." This seems to contradict
the statements in the tech-note that I based my calculations on.
(http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a0
0800fe2c1.shtml). I assume you read this one as well since it was the main
point in my previous post.
This tech note specifically states:
"In Cisco IOS Software Releases 12.2T and 12.3, the bandwidth percent
command has been made consistent among 7500 and 7200 and below. This means
that now, the bandwidth percent is not referring anymore to a percentage of
the Available Bandwidth, but to a percentage of the interface bandwidth."
I looked at the command output you attached to your reply, but that only
proves what we both already agree on, that RTP priority bandwidth is
deducted from the available bandwidth. Which is not really the issue at
stake here. How are you so sure that "All subsequent reservations are now
based on this available bandwidth value, regardless of the code version."
Apparently I'm misreading the above tech note. What is your interpretation
of this note? There must be some difference between the IOS versions,
otherwise they wouldn't elaborate on it, but it seems like we disagree on
the actual differences.
I think there's a fairly easy test to verify the correctness of the above
tech note. Again, if I read it correctly it also states:
"A class with a bandwidth percent command in a policy-map now has a fix
calculated amount of bandwidth allocated to it, and the sum of all the
bandwidth or bandwidth percent, priority and priority percent classes
together has to respect the max reserved bandwidth rule."
So basically this says that in IOS 12.2T and above the sum of the
percentages has to respect the max-reserved-bandwidth, so if it's really
calculated as a percentage of the interface bandwidth (as opposed to
available bandwidth) I should now be unable to allocate over 75% in total.
As soon as I have the time I'll upgrade one of my routers to 12.3 to see how
that works out.
I the mean time if you have any additional remarks on the statements I made
above please feel free to comment.
To be continued...
Regards,
Tom Lijnse
CCIE #11031
Global Knowledge Netherlands
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Thursday, February 26, 2004 1:27 PM
To: Tom Lijnse; 'Michael Snyder'; ccielab@groupstudy.com
Subject: RE: interplay between mqc bandwidth percent and
max-reserved-bandwidth?
> RTP priority bandwidth is deducted from the availabe bandwidth. The
> main difference when doing this on frame-relay PVCs is that in this
> case the available bandwidth isn't 75% of the interface bandwidth, but
> equals the mincir to begin with. So if I'm correct the following
> happens:
Yes.
> So assuming you're using 12.2 mainline or below the class one in your
> example would get 11% of the available bandwidth, which is 11% of 48
> kbps, which is 5.28 kbps. (This is assuming that all the traffic
> classes are present at the time, since 'bandwidth' and 'bandwidth
> percent' will give you a minimum value, not a maximum).
Yes.
> When using 12.2T or above the class one in your example will simply
> get 11% of the total bandwidth on the PVC (not the available
> bandwidth) and the total bandwidth equals the mincir, so it would get
> 11% of 96 kbps, which is 10.56 kbps.
No. The MQC is always based on this available bandwidth value.
The difference between the versions is how this available bandwidth can be
reserved with the bandwidth percent or the priority percent command.
Take the following output:
Rack1R1#sh run int s0/0
interface Serial0/0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 102
class frameshape
end
Rack1R1#sh run map-class
map-class frame-relay frameshape
frame-relay mincir 96000
frame-relay fair-queue
end
Rack1R1#show traffic-shape queue
Traffic queued in shaping queue on Serial0/0 dlci 102
Queueing strategy: weighted fair
Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
Conversations 0/0/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 96 kilobits/sec
You can see from the above output that the MQC computes the
available bandwidth for a Frame Relay PVC based on the VC's mincir value, as
this value is theoretically the provisioned rate on the circuit (i.e. you
cannot reserve more than you are guaranteed).
When a priority queue is configured, this bandwidth always comes off
of the top of the available bandwidth, before any other queueing strategies
are processed, as seen below:
Rack1R1#sh run map-class
map-class frame-relay frameshape
frame-relay mincir 96000
frame-relay fair-queue
frame-relay ip rtp priority 16384 16383 48
Rack1R1#show traffic-shape queue | in (dlci 102|Available Bandwidth) Traffic
queued in shaping queue on Serial0/0 dlci 102
Available Bandwidth 48 kilobits/sec
You can see now that the 48Kbps reserved for RTP is taken out of the
available bandwidth. All subsequent reservations are now based on this
available bandwidth value, regardless of the code version.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
>
> Available bandwidth = mincir - RTP-bandwidth = 0.5 * CIR -
> RTP-bandwidth = 0.5 * 192 kbps - 48 kbps = 96 kbps - 48 kbps = 48 kbps
>
>
>
> I would definitely be interested to see if everybody agrees with me on
> the way I do these calculations (Brian(s), Scott?).
>
> But anyway, this my take on what happens.
>
> Tom Lijnse
>
> CCIE #11031
> Global Knowledge Netherlands
>
> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@revolutioncomputer.com]
> Sent: Thursday, February 26, 2004 2:33 PM
> To: ccielab@groupstudy.com
> Cc: Tom Lijnse
> Subject: RE: interplay between mqc bandwidth percent and
> max-reserved-bandwidth?
>
>
> Thanks Tom,
>
> So 12.2 mainline or below is relative, and 12.2T or better is
> absolute.
>
> Any idea about the effect of ip rtp priority mixed with a service
> policy?
>
>
> map-class frame-relay frameshape
> frame-relay cir 192000
> frame-relay bc 1920
> no frame-relay adaptive-shaping
> service-policy output total
> frame-relay fragment 240
> frame-relay ip rtp priority 16384 16383 48
>
>
>
>
> -----Original Message-----
> From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
> Sent: Thursday, February 26, 2004 4:52 AM
> To: Michael Snyder; ccielab@groupstudy.com
> Subject: RE: interplay between mqc bandwidth percent and
> max-reserved-bandwidth?
>
> Hi Michael,
>
> The answer is: It depends....
>
> Please have a look at:
>
> http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a
> 00
> 800fe2c1.shtml
>
> This tech note states:
>
> "In Cisco IOS Software Releases 12.1T and 12.2, the percentages that
> you define in your classes are a percentage of the available
> bandwidth, rather than the full interface or VC bandwidth."
>
> on the other hand it also says:
>
> "In Cisco IOS Software Releases 12.2T and 12.3, the bandwidth percent
> command has been made consistent among 7500 and 7200 and below. This
> means that now, the bandwidth percent is not referring anymore to a
> percentage of the Available Bandwidth, but to a percentage of the
> interface bandwidth. A class with a bandwidth percent command in a
> policy-map now has a fix calculated amount of bandwidth allocated to
> it, and the sum of all the bandwidth or bandwidth percent, priority
> and priority percent classes together has to respect the max reserved
> bandwidth rule. The functionality of bandwidth percent as it was
> understood in Cisco IOS Software Releases 12.1T and 12.2 for the Cisco
> 7200 and below platforms has been preserved in Cisco IOS Software
> Releases 12.2T and 12.3 with the introduction of the new command
> bandwidth remaining percent."
>
> So basically on 12.1T or 12.2 main line your percentages would be
> relative to the available bandwidth and on 12.2T or 12.3 main line it
> would be relative to the total bandwidth and this would require you to
> bump up the max-reserved-bandwidth if you want to allocate the full
> 100%.
>
> Regards,
>
> Tom Lijnse
>
> CCIE #11031
> Global Knowledge Netherlands
>
>
>
> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@revolutioncomputer.com]
> Sent: Thursday, February 26, 2004 6:48 AM
> To: ccielab@groupstudy.com
> Subject: interplay between mqc bandwidth percent and
> max-reserved-bandwidth?
>
>
> Two questions,
>
> policy-map total
> class one
> bandwidth percent 11
> class two
> bandwidth percent 26
> class three
> bandwidth percent 4
> class four
> bandwidth percent 22
> class five
> bandwidth percent 15
> class six
> bandwidth percent 15
> class class-default
> bandwidth percent 7
>
>
> If I apply this to an interface, is the bandwidth percent valued
> calculated against the max-reserved-bandwidth? For example would
> class one be 11% of the default 75% reserved bandwidth? My total adds
> to 100%, is that of whatever the max value is, or of the total
> interface bandwidth value.
>
> I'm assuming I need to up my max-reserved-bandwidth to 100%, what if I
> didn't, would it prorate my values?
>
> ----------------------------------------------------------------------
> --
> -----
>
> Let's add some complexity.
>
>
> map-class frame-relay frameshape
> frame-relay cir 192000
> frame-relay bc 1920
> no frame-relay adaptive-shaping
> service-policy output total
> frame-relay fragment 240
> frame-relay ip rtp priority 16384 16383 48
>
> Assuming I have a 48K voice call, does the class one get 11% of what's
> left?
>
> I'm assuming I don't need a max-reserved-bandwidth command on the
> frame-relay interface.
>
> Does the service-policy (named total) in this case get what's left
> 192000-48000, then calculates the class percent values? Or does rtp
> priority and service-policy fight it out for the 192K of total
> bandwidth?
>
>
> Thanks for Your Time in Advance,
>
> Michael
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials
from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials
from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:59 GMT-3