[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Optimizing Kernel for huge iptables ruleset

Try a B-list algo(A guess).

When black listing the binary 10011010101 one would do.
match 10000000000/1
match 10000000000/2
match 10000000000/3
match 10010000000/4

and so on, not that the other rules that don't match are missing.  The
idea is that ONLY ip's that start with 10011 are checked to see if thay
match 10011010101.  The length of each check will be determined by the
full list of IP's your looking for.

Try too keep the total number of checks for ANY ip(the full set of
- low(4 to 10).

--- "Martin G.H. Minkler" <dukeofnukem@gmx.net> wrote:

> Alohá!
> The situation:
> AMD 1600 XP w/ 640 MB RAM @ 100MHZ FSB, one 3COM 905B eth1 connected to 
> LAN, one 3COM 905C connected to ADSL Modem (1024/128 line).
> Two iptables rulesets:
> The first 'normal' ruleset is pretty restrictive against connetions from
> the outside, more or less open towards connections opened from the LAN.
> The second ruleset inserted after the first is a huge IP blacklist 
> (1.4MB iptables script!) that takes nearly half an hour to be inserted 
> into the running ruleset.
> Adamantix Kernel 2.4.26 w/ PaX, stack & adress space randomization and 
> all the other goodies except for RSBAC has about every networking 
> functionality compiled in that has to do with traffic shaping/routing 
> (need to shape the LAN for the small upstream bandwidth)
> The problem:
> When transferring data, output on the NICs (well, I tested it with netio
> on eth1) is reduced to a crawling 400KB/s, top shows the system CPU load
> going up to around 94-97% while the netio process (or samba, doesn't 
> matter) tries to get another 50%+ CPU time.
> With just the first ruleset everything is fine (although the process 
> transferring still wants quite a lot of CPU for my taste).
> The question: Is my Kernel to bloated? Is there a way to further 
> optimize for networking? Can I provide more specific information (Didn't
> want to paste /usr/src/linux/.config or the like just yet ;-)?
> I have another firewall elsewhere that is running IPCop on a P200 Pro w/
> 64MB RAM and that one is taking the same blocklist without any problems,
> so I am a bit surprised to see this machine suffer. Then again that one 
> is only firewalling/routing between two 100MBit Subnets and doesn't have
> to deal with pppoe or the like. IIRC IPCop still uses a 2.2 Kernel? 
> Could it really be all the shaping functionality slowing things down so 
> much?
> best regards - at a loss
> Martin
> -- 
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org

Do you Yahoo!?
Declare Yourself - Register online to vote today!

Reply to: