Re: random detect under a policy-map

From: david robin (robindavi@gmail.com)
Date: Wed Mar 22 2006 - 15:44:07 GMT-3


Dear all,
let me be more specific the question said exactly:

 *All of the traffic that forward F/R cloud will use bandwidth 60%of S0/0 on
R5 and before Queue overflow occurs, enable random detect.*

that is the question, no more no less. what i got in my mind is that when I
use the bandwidth command the traffic will not th 60 % of the bandwidth, and
I can't limit all the traffic to use 60 % of the interface except by using
policing or shaping even after thinking i think the bandwidth command will
not be usefull too, as I know we can't enable policing with random detect,
am i right about that ?

the only option I had is using shaping as follow:

policy-map xxx

class class-default

shape average percent 60

fair queue

randon detect

**

*so do you have any thing else in mind, I read the emails and I think
threshold values in random detect will require dscp and precedence plus it
is very hard to calculate bw utilization from the values of packets in queue
and with mark probaility denominator.*

*best regards and waiting for all your replies
*

On 3/22/06, Eric.Stuhl@ferguson.com <Eric.Stuhl@ferguson.com> wrote:
>
> Sorry, I should have been more specific. I meant WRED, configuring for
> all viable precedence values.
>
>
>
> (
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_
c/fqcprt3/qcfwred.htm
> )
>
>
>
> Do we have the exact wording of the original question? That might clear up
> any inconsistencies.
>
>
>
> Eric Stuhl
>
> CCNP, CCDP, CCSE-NG
>
> Ferguson Enterprises
>
> eric.stuhl@ferguson.com
>
> (757)-969-4146
> ------------------------------
>
> *From:* Schulz, Dave [mailto:DSchulz@dpsciences.com]
> *Sent:* Wednesday, March 22, 2006 12:22 AM
> *To:* Eric Stuhl - 0018 HQ; robindavi@gmail.com
>
> *Cc:* ccielab@groupstudy.com
> *Subject:* RE: random detect under a policy-map
>
>
>
> Is that the case? Does anyone have any supporting documentation? It is
> my understanding that the RED kicks in to avoid congestion on the link
> BEFORE it happens. I can't seem to locate any documentation that supports
> this theory.
>
>
>
> This may be thinking outside the box, but maybe we could do this with
> policing....transmit up to 60% of the link speed, then....set an exceed
> action to set-dscp-transmit. Do this on the incoming interface. Then, on
> the outgoing interface...set the random detect to dscp-based. Just a
> thought.
>
>
> ------------------------------
>
> *From:* Eric.Stuhl@ferguson.com [mailto:Eric.Stuhl@ferguson.com]
> *Sent:* Tue 3/21/2006 10:13 PM
> *To:* Schulz, Dave; robindavi@gmail.com
> *Cc:* ccielab@groupstudy.com
> *Subject:* RE: random detect under a policy-map
>
> I would submit that the threshold for RED is exactly what you're looking
> for here. If you set a threshold at 60%, at that point RED kicks in and
> begins to drop packets. Before that time, packets flow normally.
>
> Eric Stuhl
> CCNP, CCDP, CCSE-NG
> Ferguson Enterprises
> eric.stuhl@ferguson.com
> (757)-969-4146
>
> -----Original Message-----
> From: nobody@groupstudy.com
[mailto:nobody@groupstudy.com<nobody@groupstudy.com>]
> On Behalf Of
> Schulz, Dave
> Sent: Tuesday, March 21, 2006 7:04 PM
> To: robindavi@gmail.com
> Cc: ccielab@groupstudy.com
> Subject: Re: random detect under a policy-map
>
> Hmmm, I am not sure if you can control "when" RED is in effect. Other
> than based on dscp or precedence. Maybe someone else has some ideas on
> this one.
>
> Dave Schulz
> *** Sent from my Blackberry ***
>
> -----Original Message-----
> From: david robin <robindavi@gmail.com>
> To: Schulz, Dave <DSchulz@dpsciences.com>
> CC: Cisco certification <ccielab@groupstudy.com>
> Sent: Tue Mar 21 18:16:35 2006
> Subject: Re: random detect under a policy-map
>
> yep,
> thats what i want , if traffic exceed 60 % enable random detect on the
> interface
>
>
> On 3/21/06, Schulz, Dave <DSchulz@dpsciences.com> wrote:
>
> That is an interesting lab question....it appears the first
> scenario
> would provide a minimum of 60 percent of the link for all
> traffic and
> also do random detect on the same traffic, since they are both
> part of
> the same class. The second one is similar, but shaping to 60%
> and also
> doing random detect on that traffic. However, the way I read
> your
> question is...to only do random detect when the threshold of 60%
> is
> exceeded. Is this what you are looking to do?
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
[mailto:nobody@groupstudy.com<nobody@groupstudy.com>]
> On
> Behalf Of
> david robin
> Sent: Tuesday, March 21, 2006 3:20 PM
> To: Cisco certification
> Subject: random detect under a policy-map
>
> dear all,
> I have a question, if said all traffic on an interface will use
> 60 % and
> you
> must enable random detection if traffic pass this limit,
> I have 2 things in minds but i dont know who will be the correct
> answer.
>
> 1- by using the bandwidth command
>
> policy-map xx
> class all-traffic
> bandwidth percent 60
> random detect
> !
> where class all-traffic will match all the traffic
> but as far as I know the bandwidth command will not reserve the
> 60 %
> untill
> there is a congetion on the physical interface itself, and
> random detect
> will not work there is a main interface congestion and the
> traffic will
> exceed 60 % Am i right about that ????
>
>
> 2- by using the shaping command and i think this will be the
> right
> answer:
>
> policy-map xx
> class all-traffic
> shape average percent 60
> random detect
> !
> I think this will be the solution?
> any comment or any other solutions about that?
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:39 GMT-3