From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Feb 26 2004 - 18:27:10 GMT-3
> 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_note09186a00
> 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:57 GMT-3