From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Feb 27 2004 - 12:07:23 GMT-3
Tom,
> As you can see the router now prevents me from assigning more than 75%
> in total because the percentage now refers to the TOTAL bandwidth, not
> the available bandwidth.
Yes.
> It simply states that 15% equals 1500 kbps, since on this IOS version
Yes, 15% of the configured bandwidth value. Prior to 12.2T, a
percentage reservation was a relative percentage of the available bandwidth.
12.2T+ a percentage reservation is an absolute reservation based on the
configured bandwidth value. In either case, what is reservable is still
governed by the available bandwidth.
Here's a snippet from the IEWB-RS solutions guide in which this
issue is covered in detail:
<IEWB-RS>
To see what the available bandwidth of an interface is issue the
show queue [interface] command:
Rack1R1#show queue e0/0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 7500 kilobits/sec
From the above output it is evident that this interface is a 10Mbps
Ethernet interface (default configured bandwidth value of 10Mbps). The
available bandwidth is 7500Kbps, which is 75% of the default interface
bandwidth of 10Mbps. This above router is running 12.2(15)T5, in which a
reservation is always absolute. The following demonstrates so:
ip cef
!
class-map match-all FTP
match protocol ftp
!
policy-map QOS
class FTP
bandwidth percent 25
!
interface Ethernet0/0
service-policy output QOS
Rack1R1#sh queue e0/0 | in Available
Available Bandwidth 5000 kilobits/sec
Notice from the above output that the available bandwidth value just
decreased by 2.5Mbps, or 25% of 10Mbps. This is an absolute reservation.
This has the same effect as if the bandwidth percent 25 statement actually
said bandwidth 2500, as seen as follows:
policy-map QOS
class FTP
bandwidth 2500
Rack1R1#sh queue e0/0 | in Available
Available Bandwidth 5000 kilobits/sec
Notice the same output. This is still an absolute reservation. In
older IOS releases, percentage reservations were relative, as follows:
Rack1R1#sh queue e0/0 | in Available
Available Bandwidth 7500 kilobits/sec
Here we see the same Ethernet interface with no prior reservations.
As max-reserved-bandwidth is 75 by default there is an available bandwidth
of 7.5Mbps. Now apply the same configuration as before:
class-map match-all FTP
match protocol ftp
!
policy-map QOS
class FTP
bandwidth percent 50
!
interface FastEthernet0/0
service-policy output QOS
!
R1#sh queue e0/0 | in Available
Available Bandwidth 7500 kilobits/sec
Although 50% of the bandwidth on this interface is reserved for FTP,
it is a relative reservation of what is available. Since the available
bandwidth on the interface is 7.5Mbps, FTP is effectively guaranteed a
minimum of 3.75Mbps (50% of 75% of 10Mbps). In order to actually reserve
5Mbps for FTP in this case there are three options.
1. Set 'max-reserved-bandwidth' to 100
interface Ethernet0/0
max-reserved-bandwidth 100
service-policy output QOS
R1#sh queue e0/0 | in Available
Available Bandwidth 10000 kilobits/sec
Since 10Mbps is now available on the interface, FTP is guaranteed
5Mbps (50% of 10Mbps). This method should be used with caution, as
reserving too much of the output queue of an interface can result in delay
or loss of necessary layer 2 and layer 3 network control packets.
2. Do an absolute bandwidth [kbps] reservation
class-map match-all FTP
match protocol ftp
!
policy-map QOS
class FTP
bandwidth 5000
!
interface Ethernet0/0
service-policy output QOS
R1#sh queue fa0/0 | in Available
Available Bandwidth 2500 kilobits/sec
bandwidth [kbps] and priority [kbps] are always absolute
reservations regardless of the IOS version, and are not based on the
available bandwidth of the interface. It is evident that after configuring
bandwidth 5000 under the FTP class, only 2.5Mbps is now available on the
interface.
3. Change the configured bandwidth value on the interface
While not very practical, the bandwidth value on the interface can
be adjusted so that the following would be true:
Interface_bandwidth = configured_bandwidth * max-reserved-bandwidth/100
Configured_bandwidth = interface_bandwidth * 100/max-reserved-bandwidth
interface FastEthernet0/0
bandwidth 133334
service-policy output QOS
R1#sh queue fa0/0 | in Available
Available Bandwidth 100000 kilobits/sec
While the third option is a roundabout solution, the point of the
exercise is to show that the available bandwidth is based on the configured
bandwidth keyword, and not a function of the physical interface.
</IEWB-RS>
Make sense?
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
>
> You can also see that very clearly from the show commands:
>
> R3#sh policy-map int e 0/0
> Ethernet0/0
>
> Service-policy output: TEST
>
> Class-map: CLASS-1 (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 1
> Queueing
> Output Queue: Conversation 265
> Bandwidth 50 (%)
> Bandwidth 5000 (kbps) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: CLASS-2 (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 2
> Queueing
> Output Queue: Conversation 266
> Bandwidth 15 (%)
> Bandwidth 1500 (kbps) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: CLASS-3 (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 3
> Queueing
> Output Queue: Conversation 267
> Bandwidth 10 (%)
> Bandwidth 1000 (kbps) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: CLASS-4 (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps
> Match: access-group 4
>
> Class-map: class-default (match-any)
> 71 packets, 6750 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: any
> R3#
>
> It simply states that 15% equals 1500 kbps, since on this IOS version
> the bandwidth percentage refers to the TOTAL bandwidth, while the new
> command 'bandwidth remaining percent' is relative to the AVAILABLE
> bandwidth.
>
> So I guess that there is actually a difference in the operation of the
> 'bandwidth percent' command depending on the IOS version.
>
> I hope this settles the issue, please let me know what you think.
>
> Regards,
>
> Tom Lijnse
>
> CCIE #11031
> Global Knowledge Netherlands
>
>
>
> -----Original Message-----
> From: Tom Lijnse
> Sent: Friday, February 27, 2004 12: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
>
> _______________________________________________________________________
> 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