Re: firewall high-load performance
Woj, another of the few joys of -digests: two birds with one stone: is there a way to check on running system how much CPU time is used to perform firewalling/traffic manager - be it pf or ipfw? Sure, compare ping times / traffic throughput with firewall turned off and on? I recall that a FreeBSD 2.2.6 P166 with about 1000 ipfw rules added up to ~2ms to ping times through - on a local 10Mbps network :) On Wed, 11 Jun 2008 00:35:14 +0200 (CEST) Wojciech Puchar [EMAIL PROTECTED] wrote: (quoting Matthew Seaman) High load may or may not be a problem depending on your traffic patterns. I've seen pf firewalls suffer by running out of state-table space in situations where there are a lot of fairly short-lived but low volume network connections. The default is 10,000 states. If your firewall machine is this state-table a hash table or something similar. if so - making it much bigger than CPU cache may actually slow down things because DRAM access latency is huge on modern machines. There was some discussion of the efficiency of ipfw stateful rules in recent weeks, over on -net IIRC. As someone else mentioned, that's the place to be if you're interested in net stuff, and are prepared to sit back and read some real expertise before saying too much for a while :) ipfw hashes src.ip ^ dst.ip ^ src.port ^ dst.port for connections in a default of 256 buckets, which is very fast when there are no collisions; duplicates however are added to a linked list, which gets slow if large, such as for raw IP or ICMP where 'port' numbers = 0. I'm not sure what stateful rules really mean in those contexts anyway, but there was talk of increasing both the (default) no. of buckets and maximum stetes kept, the memory penalty being pretty insignificant on today's hardware. I tend to doubt that processor caching is an issue one way or the other. On the whole I'd go with pf every time simply based on how much more manageable it is compared to ipfw -- you have to try, hard, to lock yourself out when reloading a new pf ruleset. i already learned well locking myself after making mistake in ipfw rules now i run screen and do something like that cd /etc cp firewall firewall.old cp firewall firewall.new edit firewall.new cp firewall.new firewall;/etc/rc.d/ipfw restart;sleep 100;cp firewall.old firewall;/etc/rc.d/ipfw restart then i have 100 seconds to quickly test new rules, at least to make sure i'm not locked. Yeah that'll work, as suggested in the manual's example. I also wouldn't mind seeing some proper empirical comparisons between ipfw and pf. Many of the reasons sometimes offered to prefer pf have been addressed in ipfw more recently (like in-kernel NAT for 7.x) and development of both is always ongoing, so it's still largely personal preference. I've been using ipfw for just over 10 years and am fairly familiar with it, and there are plenty of options I've not yet tried. Anyone reading the handbook these days would think ipfw was deprecated, and one day I hope to do a number on the ipfw section there; it contains out and out factual errors, some misconceptions and poor examples, still the author does declare his familiarity is otherwise, ipf as I recall. BTW I'm not dissing pf in any way, I've just never tried it. ipfw plus dummynet has done everything well that I've needed to do so far, mostly on networks smaller even than yours :) cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firewall high-load performance
is there a way to check on running system how much CPU time is used to perform firewalling/traffic manager - be it pf or ipfw? Sure, compare ping times / traffic throughput with firewall turned off and on? this will not measure CPU load but delays. delays are unnoticable and doesn't look like a problem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
firewall high-load performance
My preferred firewall these days, for general use, is pf. I seem to recall someone who has used it in high-load scenarios that it can kinda choke at high loads, though I don't recall whether that was due to pf itself or the fact he was running it on OpenBSD. Until now, this has not been a concern for me. I may be getting involved in a commercial project in the near future that could very well involve handling very large numbers of connections dealing with potentially high bandwidth demands, however. The circumstances would require some QOS, and I'm thinking of using pf/ALTQ for this project, but I don't want to discover after we're well underway that large numbers of connections would cause problems. Should I consider ipfw or ipfilter instead, or are my concerns with relation to pf's ability to handle extremely high loads of legitimate traffic unfounded? -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] H. L. Mencken: Democracy is the theory that the common people know what they want and deserve to get it good and hard. pgpschThvVFal.pgp Description: PGP signature
Re: firewall high-load performance
Chad Perrin wrote: My preferred firewall these days, for general use, is pf. I seem to recall someone who has used it in high-load scenarios that it can kinda choke at high loads, though I don't recall whether that was due to pf itself or the fact he was running it on OpenBSD. Until now, this has not been a concern for me. I may be getting involved in a commercial project in the near future that could very well involve handling very large numbers of connections dealing with potentially high bandwidth demands, however. The circumstances would require some QOS, and I'm thinking of using pf/ALTQ for this project, but I don't want to discover after we're well underway that large numbers of connections would cause problems. Should I consider ipfw or ipfilter instead, or are my concerns with relation to pf's ability to handle extremely high loads of legitimate traffic unfounded? pf will perform very well. I don't know if anyone has benchmarked it against ipfw, but I suspect that any difference in performance is pretty minimal. If you're just doing packet filtering and using a fairly run of the mill modern machine, you should be able to keep up with Gb wire speed without problems. If performance is a limiting factor, then review your rule sets carefully: arranging things so that the most popular traffic types are handled as early as possible, knowing when to use tables vs. use address-list macros and judicious use of quick rules can make quite a difference. Also, /stateful/ rules are generally faster than stateless once you've got beyond the initial packet that establishes the state. Looking stuff up in the state table is quicker and takes place earlier in the processing sequence than traversing the rulesets. High load may or may not be a problem depending on your traffic patterns. I've seen pf firewalls suffer by running out of state-table space in situations where there are a lot of fairly short-lived but low volume network connections. The default is 10,000 states. If your firewall machine is dedicated to running pf and it has hundreds of MB if not GB of RAM, then upping the size of some of those parameters by an order of magnitude is feasible, and works well. On the whole I'd go with pf every time simply based on how much more manageable it is compared to ipfw -- you have to try, hard, to lock yourself out when reloading a new pf ruleset. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
re: firewall high-load performance
Matthew Seaman wrote: pf will perform very well. I don't know if anyone has benchmarked it against ipfw, but I suspect that any difference in performance is pretty minimal. If you're just doing packet filtering and using a fairly run of the mill modern machine, you should be able to keep up with Gb wire speed without problems. Actually, I tracked down the guy who had originally given a poor review of pf performance, and it turns out that the missing part of his review was related to use of dummynet for bandwidth management. Since I'm not planning to use dummynet for bandwidth management, that's not really a factor we need to consider. It looks like, at this point, pf is a good choice. If performance is a limiting factor, then review your rule sets carefully: arranging things so that the most popular traffic types are handled as early as possible, knowing when to use tables vs. use address-list macros and judicious use of quick rules can make quite a difference. Also, /stateful/ rules are generally faster than stateless once you've got beyond the initial packet that establishes the state. Looking stuff up in the state table is quicker and takes place earlier in the processing sequence than traversing the rulesets. High load may or may not be a problem depending on your traffic patterns. I've seen pf firewalls suffer by running out of state-table space in situations where there are a lot of fairly short-lived but low volume network connections. The default is 10,000 states. If your firewall machine is dedicated to running pf and it has hundreds of MB if not GB of RAM, then upping the size of some of those parameters by an order of magnitude is feasible, and works well. Thanks for the further elaboration. I'll keep all this in mind as I investigate the suitability of pf for this project. On the whole I'd go with pf every time simply based on how much more manageable it is compared to ipfw -- you have to try, hard, to lock yourself out when reloading a new pf ruleset. Just one more reason pf is my favorite firewall. Thanks for the informative reply. By the way, apologies if this doesn't thread properly. I never got any messages from this thread in my inbox, and had to copy everything from the archive: http://lists.freebsd.org/pipermail/freebsd-questions/2008-June/176542.html For some reason, mutt doesn't seem to want me to alter headers to make it thread properly, and keeps throwing away my edits. -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] Dr. Ron Paul: Liberty has meaning only if we still believe in it when terrible things happen and a false government security blanket beckons. pgp5YCXSbeSg8.pgp Description: PGP signature
Re: firewall high-load performance
My preferred firewall these days, for general use, is pf. I seem to recall someone who has used it in high-load scenarios that it can kinda choke at high loads, though I don't recall whether that was due to pf itself or the fact he was running it on OpenBSD. Until now, this has not been a concern for me. it would be good to check out ipfw. at least it's IMHO much cleaner and easier to make rules i need, but it is fast. but please check, i don't have any side-to-side comparision. of course it depends how you rules are complicated and how good/bad you will define them. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
re: firewall high-load performance
Actually, I tracked down the guy who had originally given a poor review of pf performance, and it turns out that the missing part of his review was related to use of dummynet for bandwidth management. Since I'm not planning to use dummynet for bandwidth management, that's not really a factor we need to consider. It looks like, at this point, pf is a good choice. is there a way to check on running system how much CPU time is used to perform firewalling/traffic manager - be it pf or ipfw? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firewall high-load performance
High load may or may not be a problem depending on your traffic patterns. I've seen pf firewalls suffer by running out of state-table space in situations where there are a lot of fairly short-lived but low volume network connections. The default is 10,000 states. If your firewall machine is this state-table a hash table or something similar. if so - making it much bigger than CPU cache may actually slow down things because DRAM access latency is huge on modern machines. On the whole I'd go with pf every time simply based on how much more manageable it is compared to ipfw -- you have to try, hard, to lock yourself out when reloading a new pf ruleset. i already learned well locking myself after making mistake in ipfw rules now i run screen and do something like that cd /etc cp firewall firewall.old cp firewall firewall.new edit firewall.new cp firewall.new firewall;/etc/rc.d/ipfw restart;sleep 100;cp firewall.old firewall;/etc/rc.d/ipfw restart then i have 100 seconds to quickly test new rules, at least to make sure i'm not locked. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
