[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ques on Diffserv on egress side only [Jamal pls read]
On Tue, 26 Sep 2000 firstname.lastname@example.org wrote:
> > > to prevent several case of DoS attacks but new (2.4)
> > > kernel has support for it in it's netfilter.
> > You mean apart from ingress qdisc?
> yes. new firewall code can select packets not only
> by their content but also can measure their rate.
> For example:
> iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
> 1/s -j ACCEPT
> see also --limit-burst
they are slightly different. In any case, you can use ingress qdisc with
any of the classifiers whereas that code is limited to iptables.
It is probably time to start unifying some of these things to avoid
some of the redundancy (although there is no redundancy here that i see)
> > I am almost (99%) sure it doesnt. I'll give you the 1%.
> thanks for 1% chance ;-).
> Yes it WOULD be the same. but
> your proposal can't be done in linux. Instead linux will
> to it in this way:
> There is no posibility to have common queue for multiple
> output ifaces.
true. but not a problem.
> So I solved it by theorem you already said: it is the
> same to have common queue for multiple ifaces or to have
> ingres queue.
How about ingress marking and use that information on egress?
> Implement common queue for two ifaces is very complex task
> (almost unrealisable) but implementing ingres queue is simple.
Consider the ingress marking. Tag the packets from BOX2
on ingress based on some policies (eg destination subnet). They all come
through the same interface.
Do whatever you want with the tag information (route, classify etc).
If they are going to multiple outputs then why do you need the common
output queue still?
> > -> DMA -> backlog_queue -> Devik's_ingress_queue_here -> egress_queue).
> > As you can see above, delaying them at the Devik's_ingress_queue_here or
> > egress_queue would not make a difference. This is a shared bus media and
> Yes but I'm not doing it for timing reasons or because I just
> like to have queue at ingres. I only want to implement pictures
> above - to have one queue for some aggregate flow. It is hack
> but it is probably only way how to do it.
Maybe i misunderstood the requirement. You want to have some rate limiting
on ingress, from BOX2, common to all customers(link1-3 on egress), if all
are using their allocated bandwidth. If they dont, you want whoever is
available to use their bandwidth. Is that correct?
So this is solved by a combination of ingress marking/policing + spme
egress action e.g slow down excess traffic etc.
Yes, ingress queueing will also achieve this, the question is: Is it
> Is is more clear now ? have you another ide how to implement them ?