On Wed, Apr 17, 2002 at 05:20:36PM +0200, Martin Josefsson wrote: > On Wed, 2002-04-17 at 12:58, Jozsef Kadlecsik wrote: > [big snip] > > I believe the 'NOTRACK' target and 'UNTRACKED' state names are all right. > > However the 'notrack' tablename seems to be too restrictrive to me (the > > table can be used for other purposes as well); 'conntrack' would be > > misleading; 'prestate' is a little bit ugly. > > I'm just going to mention one of these other purposes. > Joakim Axelsson has built a new limit match called superlimit that is a > lot more powerful than the old limit match. If the pps against one ip in > our network exceeds X pps we can start keeping track of the pps from say > each /24 subnet against that ip and drop packets from subnets that > exceeed Y pps. > I've been testing it here on both a router and on a firewalling bridge > (transparent DoS protection) and it's been working fine. (up to 175kpps > seems to be working fine on this machine, then it starts to drop packets > at the interface level) > > The main problem with DoS-attacks is the high packet rate, usually over > 100kpps here. And the thing is that the connectiontracking takes a > really good beating (expecially since we are using SMP routers here and > the conntrack locking is one global lock and during the DoS-attack > there's a lot of inserts and deletes.)
Have you tried without conntrack? I'm not so sure it really accounts for most of the performance problems. Jamal Hadi Selmi and Robert Olsson have made several performance analysis on linux routers. You can find their test results in several papers published in conference proceedings. The major problem is that starting with a certain point, the kernel never leaves the interrupt handler to process the network rx softirq. This is a little bit better if you have a card (and driver) supporting the interrupt mitigation scheme of 2.4.x kernels. You can easily have 300kpps routed (without conntrack) with their NAPI changes which are in 2.5.x (patches for 2.4.x exist). NAPI switches the network boards into polling mode as soon as a certain load is reached. This means packets are really dropped on the network board and not within the interrupt handler or the backlog queue. *sigh* I wish I once had a couple of wire-speed traffic generators and a decent SMP x86 box to do some netfilter/conntrack benchmarking/profiling and as a result do some performance optimizations. It would be enough to be in a lab with reasonable equipment for one or two weeks.... > So we need to filter them out before conntrack and currently that seems > impossible without adding the notrack/prestate table. > /Martin -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
