From: Cristian Henry H (chenry@reuna.cl)
Date: Wed Oct 22 2003 - 12:05:42 GMT-3
Is my opinion the following:
Total bandwidth = 1000 Kbps
Requirements:
35% FTP Traffic
25% Telnet Traffic
30% Voice Traffic (and with priority as I you let us see)
So,
Configurations:
policy-map traffic
class voice
priority 300 (30% of 1000)
class telnet
bandwidth 250 (25% of 1000)
class ftp
bandwidth 350 (35% of 1000)
and I will use max-reseve-bandwidth 85 (15% of 700 = 100 Kbps aprox =
10% of 1000)
Ken.Farrington@barclayscapital.com ha escrito:
>
> I am really sorry to e-mail again on this topic, but my head is about to
> explode.
>
> (imagine its a 1Mbps cct)
> I have an excercise to do the folloiwng
>
> Users on a that share a serial line, should have the
> following restrictions
> :-
> 35% FTP Traffic
> 25% Telnet Traffic
> 30% Voice Traffic
>
> So, If I am asked a question such as the above,
>
> I should set the max-reseve-bandwidth to 90 on the interface, and configure
> the queing as such?
>
> policy-map traffic
> class voice
> priority 300
> class telnet
> bandwidth 25
> class ftp
> bandwidth 35
>
> now when I configure queueing and I have put the voice traffic into a strict
> LLQ, now my percentages change dont they?
>
> ie, we now have only 700k to play with for CBWFQ (imagine its a 1Mbps cct)
> and PLEASE NOTE, that i cant seem to find a "priority percent" command for
> LLQ - I assume one does not exist, so you have to specify LLQ in Kbits only.
>
> Is the 300k for voice correct, as I have calulated this as 30% of the total
> cct bandwidth, or should it be 30% of 900k as the max-reserved-bandwidth is
> set to 90.
>
> Also, I dont now know if I should adjust my telnet and FTP percentages to
> 25% of 700k or 25% of 600k as is the remaining bandwidth total-bandwidth
> minus LLQ reserved BW or 90% of the bandwdith minum LLQ reserved BW or will
> this just be done automatically? and I just leave these alone?
>
> I am just about to go jump in a lake :(
>
> Im sorry to persist with this, but I gues we must have a clear understanding
> of this for the lab.
>
> Many thx
>
> -----Original Message-----
> From: McCallum, Robert [mailto:robert.mccallum@thus.net]
> Sent: 22 October 2003 13:09
> To: 'Ken.Farrington@barclayscapital.com'; 'ccielab@groupstudy.com'
> Subject: RE: CBWFQ - Reseving BW for Voice
>
> Ken,
>
> The bandwidth command is the % bandwidth of the max bandwidth of the
> interface i.e. default 75% so when you specify 25% to go into a certain
> queue it is indeed 25% of 75% of interface bandwidth.
>
> Robert McCallum
> CCIE #8757 R&S
> 01415663448
> 07818002241
>
> > -----Original Message-----
> > From: Ken.Farrington@barclayscapital.com
> > [mailto:Ken.Farrington@barclayscapital.com]
> > Sent: 22 October 2003 12:24
> > To: ccielab@groupstudy.com
> > Subject: RE: CBWFQ - Reseving BW for Voice
> >
> >
> > fantasic. so if I were to get an excecise with the
> > percentages above the 75%, even thou the policy map will
> > accpt the command, just the fact that they have given me an
> > excersise totals more than the 75%, i must use the
> > max-bandwidth command to 100, of what ever the total in the
> > excercise is? Personally, I would set to the percentage
> > maximum they have specified?
> >
> >
> > correct?
> >
> > thx soo much for you help !!!
> >
> >
> > -----Original Message-----
> > From: David Bartlett [mailto:David.Bartlett@reuters.com]
> > Sent: 22 October 2003 12:00
> > To: Ken.Farrington@barclayscapital.com; ccielab@groupstudy.com
> > Subject: RE: CBWFQ - Reseving BW for Voice
> >
> >
> > Ken
> >
> > Yes, you should use LLQ's priority queue for voice traffic to
> > ensure minimal delay variations. For this exercise you must
> > set max-reserved-bandwidth to 100% as you suggest as the
> > default max is 75%. If no class-default is configured, then
> > traffic not matched by your ACLs will not be dropped but will
> > use the remaining 10% bw and be given best effort treatment.
> >
> > Another important point to understand with LLQ is that using
> > the bandwidth statement specifies the *minimum* bw that the
> > class can use during periods of congestion. However, on the
> > priority queue the bandwidth specifies the *maximum* bw that
> > the queue can use during congestion periods. The priority
> > queue is policied and traffic exceeding the configured bw
> > will be dropped.
> >
> > Hope this helps,
> >
> > David Bartlett
> >
> > -----Original Message-----
> > From: Ken.Farrington@barclayscapital.com
> > [mailto:Ken.Farrington@barclayscapital.com]
> > Sent: 22 October 2003 11:47
> > To: ccielab@groupstudy.com
> > Subject: CBWFQ - Reseving BW for Voice
> >
> >
> > All,
> >
> > Good Morning,
> >
> > Please can I confirm a couple of points.
> >
> > On the excersise below, Should I use for voice traffic, the
> > priority keyword as this I beleive invokes LLQ or should i
> > just use bandwidth (i think this may cause delay in the
> > queing of voice data and is not a good
> > idea?)
> >
> > What happens if I do not specify max-bandwidth on the
> > interface to 100 as my %s total 90% - Is this 90% of the 75%
> > that is used by default?
> >
> > If I dont specify a class-default, does all other traffic get
> > denied, or is just quese in the remain 25 percent reserved
> > for other traffic?
> >
> >
> > Please if someone could help me on these points, it would be fantasic.
> >
> > Many thx,
> > Ken
> >
> >
> > I have an excercise to do the folloiwng
> >
> > Users on a that share a serial line, should have the
> > following restrictions
> > :-
> > 35% FTP Traffic
> > 25% Telnet Traffic
> > 30% Voice Traffic
> >
> > so, using CBWFQ config as below
> >
> > map-class voice
> > match access-group 100
> > map-class telnet
> > match access-group 110
> > map-class ftp
> > match access-group 120
> >
> > policy-map traffic
> > class voice
> > priority 30
> > class telnet
> > bandwidth 25
> > class ftp
> > bandwidth 35
> >
> >
> > acess-list ............
> >
> >
> > --------------------------------------------------------------
> > ----------
> > For more information about Barclays Capital, please
> > visit our web site at http://www.barcap.com.
> >
> >
> > Internet communications are not secure and therefore the Barclays
> > Group does not accept legal responsibility for the contents of this
> > message. Although the Barclays Group operates anti-virus programmes,
> > it does not accept responsibility for any damage whatsoever that is
> > caused by viruses being passed. Any views or opinions presented are
> > solely those of the author and do not necessarily represent
> > those of the
> >
> > Barclays Group. Replies to this email may be monitored by
> > the Barclays
> > Group for operational or business reasons.
> >
> > --------------------------------------------------------------
> > ----------
> >
> > ______________________________________________________________
> > _________
> > 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
> >
> >
> > --------------------------------------------------------------- -
> > Visit our Internet site at http://www.reuters.com
> >
> > Get closer to the financial markets with Reuters Messaging -
> > for more information and to register, visit
> > http://www.reuters.com/messaging
> >
> > Any views expressed in this
> > message are those of the individual sender, except where
> > the sender specifically states them to be the views of Reuters Ltd.
> >
> > ______________________________________________________________
> > _________
> > 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
-- Cristian E. Henry REUNAE-mail: chenry@reuna.cl Fono: 56-2-3370336
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:06 GMT-3