On Fri, Jan 19, 2007 at 12:31:27PM +1300, Jasper Bryant-Greene said:
I know that iptables isn't hugely fast, there's a reason you pay for Ciscos etc etc, but the resources I have read usually indicate that iptables slowness is related to massive rulesets. We have 2415 rules, which I don't consider to be *that* many...
It's getting up there. Depending on the CPU of the box, that could severely overtax a firewall. I've a VIA C3 600Mhz box with 2550 rules that can pass 10.8MByte/s through it for sustained periods (minutes) - I suspect that's being capped by 100Mb interfaces and other traffic in/out of the boxes.
Anybody encountered anything similar? Is it likely to simply be related to the number of rules?
I've a couple of boxes that have over 4000 rules, and are suffering - if I take them down to under 2000 rules, they perform vastly better. The actual cutoff point seems to be primarily CPU performance related - slower boxes will fail at 1000 rules, fast boxes might cope with 5000. I'd try reordering the rules to get the most often hit rules at the top of the list, turning on NAPI if you haven't already, or moving to nf-hipac (if you don't need NAT/MANGLE). The PDF's at http://www.hipac.org/documentation/presentations.html are interesting - if I recall correctly one of them has a graph of throughput versus no of iptables rules which said that on their particular hardware with up to 1000 rules they got 100Mb/s, above that throughput started to tail off and at 5000 rules they got essentially 0Mb/s. Performance to the hipac website blows at the moment, which might not be the best advertisement for the software :-). Cheers Si