From: Eric.Stuhl@ferguson.com
Date: Wed Mar 22 2006 - 10:34:42 GMT-3
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
(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] 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] 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?
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:39 GMT-3