RE: LLQ with Bandwidth MQC

From: Babatunde Sanda <sbabatunde1_at_ca.rr.com>
Date: Wed, 25 Nov 2009 20:43:30 -0800

I forgot to include the " max-reserved-bandwidth 80" under the serial interface

INT S0/0
max-reserved-bandwidth 80
service-policy output INTERNET_TRAFFIC

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of sbabatunde1_at_ca.rr.com
Sent: Wednesday, November 25, 2009 7:40 PM
To: S Malik; ALL From_NJ
Cc: Cisco certification
Subject: Re: LLQ with Bandwidth MQC

Hello Malik,

Here is a quick QOS MQC run down (there is way more to QOS though). The command "max-reserve bandw" is to modify the default reserved bandwidth on interfaces which is 25% of the interface by default. This is needed for the "class-default" (any traffic not explicitly classified for in your configuration. So when you configure traffic with MQC you are actually using the remaining 75% on the interface. You shouldn't have to modify the reserved bandwidth except absolutely necessary because you definitely cannot classify for all traffic. If my memory serves me I think the maximum class recommended is 11 and minimum is 4. So you want to make sure there is bandwidth for this traffic's to use (As usual Cisco will give you the command to shoot yourself in the foot even though they recommend otherwise).

When configuring LLQ, you use the command priority percent "bandwidth percent" or priority bandwidth "bandwidth amount". When you do this you are policing the class you specified to the amount in percentage or specified bandwidth amount. In other words this command is saying the traffic will not get more than the amount if congestion happens.

On the other hand when you use the "bandwidth percent or bandwidth followed by the bandwidth amount" you are saying to the class "you get this amount if congestion happen and if there is more bandwidth and you need more you can use more.

So for example say I want to classify for this 3 traffic voice, video and Gnutella and I want to use 80 percent of the total bandwidth on the interface I will do something like this.

TRAFFIC CLASSIFICATION

class-map match-any VIDEO
  match ip dscp 41
class-map match-any VOICE
  match ip dscp ef
class-map match-any TRASH
  match protocol gnutella

ACTION

policy-map INTERNET_TRAFFIC
  class VOICE
   set dscp ef
   priority percent 33
  class VIDEO
   set dscp 41
   bandwidth percent 10
  class TRASH
   set dscp af11
   bandwidth percent 2
  class class-default
   fair-queue
   random-detect dscp-based

APPLICATION

INT S0/0
service-policy output INTERNET_TRAFFIC

Hope this gives you a better insight and encourage you to read more on QOS.

Good luck.
---- S Malik <ccie.09_at_gmail.com> wrote:
> All,
> I have deliberately configured three classes with BW statement under a
> policy-map so that it consume 75% of BW.
>
> Fourth class I configured with priority %25. Now I could configure
> service-policy out on interface by changing "max-reserve bw 76%.
>
> I think, BW 25% command under policy-map means minimum 25% and priority 25%
> means upto 25%.
>
> What I like to confirm is that if I keep max-reserve BW 76% then only 1% of
> BW will be used for LLQ?
>
> On Wed, Nov 25, 2009 at 11:39 AM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
>
> > If you have configured more bandwidth than what is avail, you will see the
> > error message telling you that you do not have enough. You can use the
> > max-reserv command to alter what is available for your configuration.
> >
> > The link:
> >
> > http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m1.html#wp1039174
> >
> > By default you can only configure up to 75% of the bandwidth. Use this
> > command when you want to configure more. In your example, 24% would still
> > be available for class-default, aka ... unnamed traffic that does not match
> > your class-maps.
> >
> > The percent command will be a percentage of the available bandwidth. The
> > above link can also be used for looking up these commands as well.
> >
> > IMO, the percentage commands are very good when you are offering a service
> > to another or when you want to standardize a QoS config.
> >
> > For example, network management traffic will always get at least 5% of the
> > bandwidth or biz traffic will always get 40% of bandwidth etc ...
> >
> > Some service providers might offer different service levels at different
> > prices. An example of these might look like:
> >
> > VoIP always get 25%
> > Net Management always gets 5%
> > Ip Prec 3 might always get 30%
> > IP Prec 4 .... gets 15%
> > etc ...
> >
> > If you are a service provider, you can apply these configs to any link and
> > maintain the same service levels regardless of the actual bandwidth of the
> > link. Voip will still always get 25% whether it is on a T1 or T3 ...
> >
> > Does this make sense? I hope my examples are clear (many times I confuse
> > myself :-))
> >
> > HTH,
> >
> > Andrew Lee Lissitz
> > .
> > On Wed, Nov 25, 2009 at 11:18 AM, S Malik <ccie.09_at_gmail.com> wrote:
> >
> >> ALL,
> >>
> >> if I have three classes of traffic each with 25% of minimum BW and 4th
> >> class
> >> of traffic with priority percent 25 then all I need for the service-policy
> >> command to go through under interface is "max-reserve bw 76%".
> >>
> >> My question is that in this case only 1% of BW will be allocated to the
> >> traffic which is configured for LLQ?
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Andrew Lee Lissitz
> > all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Nov 25 2009 - 20:43:30 ART

This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:29 ART