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
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
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
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
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
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
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
