Hi, I have done a few benchmarks which may be of some use. TEST SETUP. ---------------------------------------------------------------------- machine A: 600Mhz PIII, ~650MB RAM, Windows 2000 professional, 3Com 3c905B running half duplex.
GW: 1.133GHz, 512MB RAM, 2.4.18rc2aa2, iptables 1.2.5, intel 100MB running half duplex, and 1000MB ns83820 running full duplex. machine B: dual PII 450, 1GB RAM, Linux 2.4.18rc2aa2, 1000MB ns83820 running full duplex. Network diagram: A----GW----B :-) ---------------------------------------------------------------------- TEST 1. ---------------------------------------------------------------------- The results I got with ttcp are (the average of 3 test): 1 Rule in FORWARD chain ( -s internalnets -j ACCEPT) B -> A = 7820 KB/sec A -> B = 10141 KB/sec 101 Rules B -> A = 7836 KB/sec A -> B = 9591 KB/sec 201 Rules B -> A = 7894 KB/sec A -> B = 9963 KB/sec Chains based on protocol 100 Rules in TESTING chain. B -> A 7786 KB/sec A -> B 9541 KB/sec Chains based on interface. 100 Rules in TESTING chain. B -> A 7852 KB/sec A -> B 9695 KB/sec ---------------------------------------------------------------------- TEST 2: ---------------------------------------------------------------------- Using ttcp from machine B to ttcp running on GW. GW<-B OUTPUT has no rules and has default policy of accept. 3 RULES (a couple of reject rules and -i gigacard -j ACCEPT) 46536KB/sec (average of 3) 2003 RULES. (50% -A INPUT -p tcp -s 1.1.1.1 -d 2.2.2.2 -m state --state NEW -j DROP" 50% -p udp -s 1.1.1.1 -d 2.2.2.2 -m state --state NEW -j DROP) 12722KB/sec (average of 3) 3003 RULES (same as above) 5038KB/sec (average of 3) ---------------------------------------------------------------------- You can do optimisation of the rules, splitting rules with parts in common into chains, ie source, protocol, interface etc, so that a packet doesn't have to pass as many rules. For example with the 3000 udp/tcp rules above when split into two chains (-A INPUT -p udp -j UDP_CHAIN, & _A INPUT -p tcp -j TCP_CHAIN) each with 1500 rules each, the ttcp benchmark gives ~24433KB/sec. Also organising the rules so that you have a rule: $IPTABLES -A INPUT/FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT as early as possible. For example with a setup like the 3003 rule test above [Reject rule 1] [Reject rule 2] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT [Test Rule 1] [Test Rule 2] [Test Rule 3] ... [Test Rule 3000] -A INPUT -i gigacard -j ACCEPT gives ~42728KB/sec. Hope this helps. Craig Knox On Mon, 2002-03-04 at 09:29, Markus Schaber wrote: > Hi, > > Our university network (134.60.*.*) currently uses a Checkpoint > firewall, but (due do some problems) we want to switch to a linux 2.4 > iptables firewall. > > Currently, we have an allow all, deny some policy, but our new (planned) > policy would be deny all, allow some with udp and incoming tcp, and deny > some on outgoing tcp. > > As there is no real pattern regarding which IP addresses provide which > services (each local department admin is free to offer services - this > is a university), this could easily result in a few thousand rules. > > As the firewall has to cope with about 600 MBit peak bandwidth, > scalability is an issue. A linear walk-through over those thousands of > rules would sure be much to slow. > > I did some googling, and scanned through the FAQ and most of the Howtos > on netfilter.samba.org, but didn't find anything useful about > scalability. > > So now our question is: How scalable is the linux firewalling > architecture? Is there any internal optimization on the rules? > > Do you have any pointers to documentation or benchmark results about > this? > > Thank you very much, > markus > -- > "Ihre Meinung ist mir zwar widerlich, aber ich werde mich dafuer > totschlagen lassen, dass sie sie sagen duerfen." - Voltaire >
