Sorry for the slow response. My thanks also to Jason, Daniel, and Aleksandar for their thoughtful responses. Joining this list and perusing others' daily networking/routing issues has been a huge wake-up call to me. I'm very thankful for this community of developers, admins., and users. Mike On Sat, 2 Oct 2004 12:19:27 +0600, Askar <askarali@xxxxxxxxx> wrote: > Thanks Jason, Aleksandar now the things kinda clear to me about the > magic of "optimize" a ruleset :) > > regards > askar > > On Fri, 01 Oct 2004 16:09:03 -0500, Aleksandar Milivojevic > > > <amilivojevic@xxxxxx> wrote: > > Mike wrote: > > > Me too--- I'd like to learn what it means to optimize my iptables. > > > After using iptables for 2 years but never really taking the time to > > > digest what it means to filter data across tables, I'm trying to > > > really understand what's going on. I've started with Oskar > > > Andreasson's tutorial, but I definitely don't see anything about > > > optimization in there. > > > > It can mean many things, and depends on actual configuration and needs. > > Idea behind optimization is to minimize average number of rules that > > packets will traverse. > > > > Simple example could be if you have bunch of rules with "-m state > > --state NEW" and than somewhere at the end you have catch-all "-m state > > --state ESTABLISHED", moving that rule to the top will make huge > > difference (because majority of packets will be matched by it). > > > > On a very bussy site with simple set of rules (but huge number of > > simultanious connections) eliminating connection tracking could increase > > performance (if traversing couple of rules is faster than lookup into a > > huge table, of course). I don't know how connection tracking table is > > organized and how the entries are looked up, so don't ask me for a > > numbers when it makes sense not to use connection tracking, but majority > > of people probably wouldn't benefit from turning it off. However, do > > note that this will be tradeoff between performance and security. > > > > Another example is if you have bunch of rules allowing access to service > > only from certain IP addresses (say there's 20 of them). Creating user > > defined chain for that service (for example -p tcp --dport 80 -j HTTP), > > and than checking if packet is from one of 20 allowed IP addresses means > > that all other packets will have to be checked only by 1 rule, not by 20 > > of them. Or you can go the other way around, if you are checking single > > IP address agains number of services (in this case using multiport > > module can be usefull too). Something like -s a.b.c.d -j CLIENT_A. > > > > These are just some simple and obvious examples. The idea is to > > minimize number of checks that need to be done on a packet before it is > > accepted or dropped. Obviously, what can be done differs from one > > config to another. > > > > P.S. > > Offtopic: seems that Google mail is becoming quite popular on the > > mailinglist... > > > > -- > > Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited > > Systems Administrator 1499 Buffalo Place > > Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 > > > > > > > -- > (after bouncing head on desk for days trying to get mine working, I'll make > your life a little easier) > >
