From: Banks, Ethan (Ethan.Banks@ChasePaymentech.com)
Date: Mon Jan 07 2008 - 10:21:14 ARST
Priority queueing (LLQ) will do rate-limiting. While "bandwidth" will
guarantee a minimum bps allocated to a traffic-class during congestion,
more bps can be used if available. OTOH, "priority" is a guaranteed
minimum bps but also a hard ceiling - traffic assigned to the priority
queue can not use more than the bps assigned to it. I don't know that
this is an exact fit for the scenario problem, but it's a thought.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hq
os_r/qos_o1h.htm#wp1076758
QoS command - priority
"Syntax Description/bandwidth-kbps
Guaranteed allowed bandwidth, in kbps, for the priority traffic. The
amount of guaranteed bandwidth varies according to the interface and
platform in use. Beyond the guaranteed bandwidth, the priority traffic
will be dropped in the event of congestion to ensure that the
nonpriority traffic is not starved."
/Ethan - CCIE Candidate Blog
http://www.ethanbanks.net
|-----Original Message-----
|From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
|Behalf Of darth router
|Sent: Sunday, January 06, 2008 11:20 PM
|To: Wollmann, Bruno RQHR
|Cc: Mark Turner; ccielab@groupstudy.com
|Subject: Re: QOS Conundrum - bandwidth, shape average or shape peak?
|
|Bandwidth could be the
|answer. The keyword "limited" probably means policing. The
|problem we have
|here is this looks like a poorly interpreted ccie lab ripoff question
|(educated guess), meaning that we don't really know what the
|exact question
|is. So whoever magicked up the question needs to work on their
|photographic memory skills and get the Q right.
|I'll leave it at that :P
|
|DR
|
|On 1/6/08, Wollmann, Bruno RQHR <Bruno.Wollmann@rqhealth.ca> wrote:
|>
|> You want to use SHAPE AVERAGE for the PREC2 traffic. SHAPE PEAK will
|> allow more than 128K if it's available (how much more I don't know).
|> Using BANDWIDTH 128 for PREC2 will guarantee 128K of
|bandwidth and allow
|> more (upto the interface bandwidth) if there is no
|congestion, it will
|> not limit it to 128K. You definitely don't want to use BANDWIDTH.
|>
|> HTH
|> Bruno
|>
|> -----Original Message-----
|> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]
|On Behalf Of
|> Mark Turner
|> Sent: January 6, 2008 5:07 PM
|> To: ccielab@groupstudy.com
|> Subject: QOS Conundrum - bandwidth, shape average or shape peak?
|>
|> Hello,
|>
|> I am trying to solve the below question. I have included the
|> configuration that I believe will work. I am just unclear as
|to the best
|> method to rate limit to a specific value if rate limiting
|and policing
|> are specifically forbidden. I have narrowed it down to the shape
|> average, shape peak or bandwidth statement but cant decide
|which to use.
|>
|> "Configure R2 so that traffic marked with the precedence
|value 3 AND/OR
|> traffic from VLAN_C (1.1.1.1) to VLAN_BB2 (2.2.2.2) is guaranteed
|> minimum of 128K of bandwidth when sent out of interface fast 0/0. If
|> congestion occurs assure this traffic is randomly dropped. Also make
|> sure that traffic marked with prec value 2 is rate limited
|to 128K. Do
|> not use rate-limiting or policing."
|>
|> Access-list 100 permit ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255
|>
|> class-map match-any prec3
|> match ip precedence 3
|> match access-group name prec3
|> !
|> class-map match-any PREC2
|> match ip precedence 2
|> !
|> policy-map cisco
|> class VLANC-TO-VLAN_BB2
|> bandwidth 128
|> random-detect
|> class PREC2
|> shape average 128000 -> my best guess
|>
|> OR
|> class PREC2
|> shape peak 128000
|>
|> OR
|> class PREC2
|> bandwidth 128
----------
Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com.
THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:58 ARST