From: Venkataramanaiah.R (vramanaiah@gmail.com)
Date: Sun Nov 27 2005 - 15:51:17 GMT-3
Chris, for #1, I can see what you mean, agree that when we configure
RED on an I/f, it shows the queueing strategy as RED, but dont you
think RED is actually acting on FIFO queue there? This was my
clarification question.. Correct me if i am still wrong in my
understanding.
Regards
-Venkat
On 11/27/05, Chris Lewis <chrlewiscsco@yahoo.com> wrote:
> Question 1 does not make sense to me, please try again with some CLI and
> router responses to clarify what you mean. For 2, RED works on the queues
> built up by WFQ.
>
> Chris
>
> "Venkataramanaiah.R" <vramanaiah@gmail.com> wrote:
> Chris,
>
> Ok.. Nice and detailed explanation and it is inline with most of my
> understanding as well, but as i warned here are my follow up
> questions..
>
> 1) Did you really mean that RED can't work on FIFO? If so, does the
> queuing stratregy change from FIFO (Am afraid not) to something else
> when bandwidth is configured under a class for that particular class.
> I thought it is FIFO always under a particular class.
>
> 2) For the class-default, how does work RED work when just fairqueue
> is configured. It still doesnt know how to measure the drop threshold
> right? or does it behave like WFQ's CDT and not as a true RED, when
> fairqueue is configured?
>
> Thanks
> -Venkat
>
>
> On 11/27/05, Chris Lewis wrote:
> >
> > Venkat,
> >
> > There are several concepts represented in your mail that need to be
> > separated in order for a full understanding to be possible. I also think
> > that some of this is not relevant to the R&S exam, but anyway, here is
> what
> > I can tell you right now.
> >
> > First, in terms of deciding which packet to drop, FIFO is mutually
> exclusive
> > from RED. One either decides to tail drop packets in the case of FIFO, or
> > randomly drop packets before the tail drop case is reached via RED.
> >
> > If your question is "why do I need to configure bandwidth in order to
> > configure RED" the answer is you don't J
> >
> > RED can be applied to an interface or a class. Looking at the interface
> > application first
> >
> > interface Serial0/0
> > no ip address
> > random-detect dscp-based
> > end
> >
> > Then looking at the interface gives the following:
> > sho int s0/0
> > Queueing strategy: random early detection(RED)
> >
> > So here we have no bandwidth or fair queueing defined in the configuration
> > and RED can be applied. So the next question is, what happens when I try
> to
> > apply RED to a class
> >
> > class-map match-all map1
> > match protocol icmp
> >
> > Router(config)#policy-map test1
> > Router(config-pmap)#class map1
> > Router(config-pmap-c)#random-detect
> > bandwidth on the class is required to issue this command
> >
> > So now we have different behavior. The reason for the difference is that
> an
> > interface has a given throughput capability, and when that is reached, a
> > queue will build up and RED can act upon that queue. By contrast, a class
> > can have any throughput capability configured on it, so there is no
> natural
> > throughput level (other than the interface capability) that will build a
> > queue to enable RED to act. So think of a class as something virtual
> within
> > the router that you need to define the capabilities of in order for RED to
> > do its thing.
> >
> > Now the situation changes slightly for the default class.
> >
> > Router(config-pmap)#class class-default
> > Router(config-pmap-c)#rand
> > Router(config-pmap-c)#random-detect
> > fair-queue or bandwidth on the class is required to issue this command
> >
> > The difference here is that the default class uses the remaining
> unallocated
> > bandwidth (unallocated to other classes), so it does not strictly need the
> > bandwidth statement, as it knows the amount of bandwidth left and can work
> > with that.
> >
> > Now RED is in fact a dropping mechanism, and it needs a queue to operate
> on.
> > As classes are virtual within the router (as opposed to a physical
> > interface) some queueing strategy needs to be defined for the class to
> > define how to build these queues, and for the class-default you are given
> > the additional option of defining fair-queueing.
> >
> > There are two other RED options to be familiar with. Flow based (for
> > interfaces only) and the ECN option. Flow based was created for non-TCP
> > flows that do not back off in the presence of dropped packets. The ECN
> > option is where you can set ECN in the packet instead of dropping it, so
> > that you do not have to rely upon the dropping of a packet to signal
> > congestion (and by implication hosts will know to back off without
> > experiencing packet loss).
> >
> > Chris
> >
> > "Venkataramanaiah.R" wrote:
> > Read the last but one para as,
> >
> > "Why can't random detect work on a FIFO queue. What i mean here
> > is why i cant configure RED on a FIFO queue (w/o bandwidth statement,
> > assuming bw
> > command changes the queue to WFQ)."
> >
> > TIA
> > -Venkat
> > On 11/27/05, Venkataramanaiah.R wrote:
> > > Hi Chris/all,
> > >
> > > Is there any theory behind, why CBWFQ class does not accept
> > > random detect command w/o bandwidth command?
> > >
> > > Might be a silly question, but just want to get the basics clear..
> > >
> > > Does the queuing strategy get changed for the class when
> > > bandwidth command is configured.. May be WFQ..?
> > >
> > > Why can't random detect work on a FIFO queue. What i mean here
> > > is why i cant configure RED w/o bandwidth statement (Assuming bw
> > > command changes the queue to WFQ).
> > >
> > > Warning : I may have more questions based on your response.
> > > Hope this warning does not prohibit you from answering the above
> > > questions :-)
> > >
> > > Regards
> > > -Venkat
> > >
> >
> >
> >
> > ________________________________
> > Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
> >
> >
>
>
>
>
> ________________________________
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:08 GMT-3