2002-04-17 21:16:40+0200, Harald Welte <[EMAIL PROTECTED]> -> > On Wed, Apr 17, 2002 at 05:20:36PM +0200, Martin Josefsson wrote:
> > 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. > > 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 problem is that we still want to use the conntrack. We have both (me and Martin Josefsson) used NAPI and its pre-versions since kernel 2.4.0-test in our routers. We (me and Martin) has discussed a table, "border", that is the absolutly first thing that is being travered after leaving the netcard driver. Meaning we get a chance to throw away packets even before tcpdump gets a chance to have a look. Ofcouse won't conntrack be available here. But that's exactly what we want. A table to be at the border having a change to either have superlimit/limit working here or manually add rules as we get attacked. We want the packets away from the system as fast as possible when we are talking about over 100K pps. Null-routing is too slow. It uses memory (route cache) and time to actually route it to null. Leting it go to conntrack, well you know how good conntrack is with DoS. So far our router has managed to stay alive on 100K pps DoS going through conntrack. But CPU is at 100% and normal traffic get hit badly. We see large attack, over 100kpps on our 100Mbit links. The computer (router) will die unless we are using limits. Not using conntrack isn't a solution, since we need it "later" in our rules routing/firewalling rules. The network I'm admin for has one of the IRC-network EFnet oldest server. We do get attacked :-) > 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. > > > So we need to filter them out before conntrack and currently that seems > > impossible without adding the notrack/prestate table. > We would like to call this "border". Just the same as "filter INPUT", but the absoluty first thing that happens after the packet comes from the netcard-driver. Behaps a border OUTPUT doing the same thing just before entering the netcard driver. But it's not really needed more than in anti spoof and debuging of your own network. Meaning border INPUT is enough, really. Any solution with being able to mark packets for "NOTRACK" or anything is just too complicated in our need; handling DoS. Everything that do get pass "border" is conntracked (if conntrack is loaded). Plain and easy. However i can see that people would like the solution of letting packet get "flagged" notrack. Second, developing this new hashslab (named hashslot in my patched i sent in) now using a slab and much better SMP-performace, me and Martin has plans to rewrite conntrack_core using this structure. Its very fast and very flexable. We just need to test it some more with simulated DoS and DDoS attacks (superlimit using this new hashslab structure). So far its has had very nice figures. Benifits are two: 1. Rehash of the discussed hashtable 2. Take advantage of SMP systems by using smarters lock, not only global lock aorund it all. Thanx! -- /Joakim Axelsson A.K.A Gozem@EFnet & OPN
