From: Tom Lijnse (Tom.Lijnse@globalknowledge.nl)
Date: Fri Feb 27 2004 - 08:06:18 GMT-3
Hi Brian,
To be able to verify the potential differences between 12.2 and 12.3 I
upgraded one of my routers to 12.3(6) mainline:
R3#sh ver
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-IS-M), Version 12.3(6), RELEASE SOFTWARE
(fc3)
<snip>
I subsequently configured a service policy on a regular ethernet
interface and started assigning bandwidth percentages to some classes:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#policy-map TEST
R3(config-pmap)#exit
R3(config)#int e 0/0
R3(config-if)#service-policy output TEST
R3(config-if)#exit
R3(config)#class-map CLASS-1
R3(config-cmap)#match access-group 1
R3(config-cmap)#class-map CLASS-2
R3(config-cmap)#match access-group 2
R3(config-cmap)#class-map CLASS-3
R3(config-cmap)#match access-group 3
R3(config-cmap)#class-map CLASS-4
R3(config-cmap)#match access-group 4
R3(config-cmap)#policy-map TEST
R3(config-pmap)#class CLASS-1
R3(config-pmap-c)#bandwidth ?
<8-2000000> Kilo Bits per second
percent % of total Bandwidth
remaining % of the remaining bandwidth
R3(config-pmap-c)#bandwidth percent 50
R3(config-pmap-c)#class CLASS-2
R3(config-pmap-c)#bandwidth percent 15
R3(config-pmap-c)#class CLASS-3
R3(config-pmap-c)#bandwidth percent 10
R3(config-pmap-c)#class CLASS-4
R3(config-pmap-c)#bandwidth percent 10
I/f Ethernet0/0 class CLASS-4 requested bandwidth 10%, available only 0%
R3(config-pmap-c)#^Z
R3#
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.
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
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:58 GMT-3