From: Kenneth Wygand (KWygand@customonline.com)
Date: Fri May 28 2004 - 08:47:33 GMT-3
Chris,
Yes, the "priority xxx" command used when configuring LLQ provides that amount of bandwidth for a priority queue (always the first packet to leave the CBWFQ) while also policing to that configured bandwidth. So it's multi-purpose.
HTH,
Ken
-----Original Message-----
From: Lord, Chris [mailto:chris.lord@lorien.co.uk]
Sent: Fri 5/28/2004 6:29 AM
To: Brian McGahan; Kenneth Wygand; ccielab@groupstudy.com
Cc:
Subject: RE: bandwidth-percent in class-default
Thanks Brian, I see the point at long last. It got me thinking though, can you confirm my understanding that if a named class has an LLQ then this does have an inbuilt policer. If for example you are using an LLQ for voice, then presumably any excess voice traffic will be dropped by the LLQ policer rather than joining the bun-fight for bandwidth in the class-default and potentially being subjected to different queueing policies (WFQ) which could cause jitter?
Thx,
Chris.
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: 27 May 2004 15:13
To: Lord, Chris; Kenneth Wygand; ccielab@groupstudy.com
Subject: RE: bandwidth-percent in class-default
Chris,
A bandwidth reservation in the MQC does not have a built in
policer. It is simply a minimum bandwidth reservation in the case that
the output queue is full. Traffic of the defined class can still exceed
the reserved value though. What you can run into with the first example
is FTP saturating the line. As default traffic is not reserved, it is
possible that it may not get admission to the output queue.
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
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Lord, Chris
> Sent: Thursday, May 27, 2004 6:05 AM
> To: Kenneth Wygand; Brian McGahan; ccielab@groupstudy.com
> Subject: RE: bandwidth-percent in class-default
>
> I'm only a rookie but......
>
> Whilst Brian's comment are absolutely correct, in practice, surely
option
> 1 & 2 give the same result given that there is only an FTP class and a
> class-default. Non-FTP traffic would only get less than 10% if a third
> class was to be introduced later.
>
> It's also my understanding that there are differences between the
version
> of IOS you are using. I'm not sure when it changed (12.2 ish) but in
> earlier versions the bandwidth command "specified bandwidth allocation
as
> a percentage of the max-reserved-bandwidth". In later version the
> bandwidth command "specifies bandwidth as a percentage of the
underlying
> link rate". So....
>
> Older IOS & Option 1 gives
>
> FTP: 90% (BW) of 90% (MRB) = 81% of link speed
> non-FTP (inc protocals and everything else) gets remaining 19% of link
> speed
>
> Older IOS & Option 2 gives
>
> FTP: 90% (BW) of 100% (MRB) = 90% of link speed
> non-FTP (inc everything else) gets remaining 10% of link speed
>
> Newer IOS and Option 1 and 2 gives
>
> FTP: 90% (BW) of link speed
> non-FTP (inc everything else) get remaining 10% of link speed
>
> On the newer IOS the max-reserved-bandwidth command only seems to
serve as
> a warning marker during configuration rather than affecting the maths.
Or
> am I completely off-course here?
>
> Regards,
>
> C.
>
>
>
>
>
>
> -----Original Message-----
> From: Kenneth Wygand [mailto:KWygand@customonline.com]
> Sent: 27 May 2004 06:18
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: RE: bandwidth-percent in class-default
>
>
> Hey Brian,
>
> I see... FTP traffic can basically get more than 90% of traffic with
my
> first configuration during congestion while other traffic would be
> guaranteed the other 10% of traffic during periods of congestion.
>
> My real uncertainty lies in the "class-default". Does
system-generated
> traffic (routing processes, etc) fall into this class or would that
> traffic potentially starve if all remaining bandwidth (to fill up
100%)
> was guaranteed in the class-default (of course this could only be done
by
> changing the "max-reserve-bandwidth" value to 100%).
>
> TIA,
> Ken
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Thu 5/27/2004 1:08 AM
> To: Kenneth Wygand; ccielab@groupstudy.com
> Cc:
> Subject: RE: bandwidth-percent in class-default
>
>
>
> Ken,
>
> Yes there is a difference. In the first configuration
non
> FTP
> traffic is not guaranteed bandwidth in the case of congestion.
In
> the
> second configuration, non FTP traffic is guaranteed 10% of the
> output
> queue in the case of congestion.
>
> 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
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> Of
> > Kenneth Wygand
> > Sent: Wednesday, May 26, 2004 10:04 PM
> > To: ccielab@groupstudy.com
> > Subject: bandwidth-percent in class-default
> >
> > Is there a difference between the results of the following
> configurations?
> >
> > My requirement is to reserve 90% of the interface bandwidth
for
> FTP
> and
> > 10% for everything else. Note the explicit
"bandwidth-percent"
> > configuration command under the "class-default" my policy-map.
> >
> > <snip>
> > OPTION 1:
> > class ftp
> > match protocol ftp
> > policy-map 90forFTP
> > class ftp
> > bandwidth-percent 90
> > interface s0
> > max-reserve-bandwidth 90
> > service-policy 90forFTP
> >
> > OPTION 2:
> > class ftp
> > match protocol ftp
> > policy-map 90forFTP
> > class ftp
> > bandwidth-percent 90
> > class class-default
> > bandwidth-percent 10
> > interface s0
> > max-reserve-bandwidth 100
> > service-policy 90forFTP
> > </snip>
> >
> > Thanks in advance,
> > Ken
> >
> >
>
____________________________________________________________________
> ___
> > 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
>
>
> **********************************************************************
> The information contained in this email is confidential and is
intended
> for the recipient only. If you have received it in error, please
notify us
> immediately by reply email and then delete it from your system. Please
do
> not copy it or use it for any purposes, or disclose its contents to
any
> other person or store or copy this information in any medium. The
views
> contained in this email are those of the author and not necessarily
those
> of Lorien plc.
>
> Thank you for your co-operation.
> **********************************************************************
>
>
_______________________________________________________________________
> 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 : Wed Jun 02 2004 - 11:12:18 GMT-3