* Steve Johnson <maill...@sjohnson.info> [2011-02-01 20:35]: > I currently have a system that has no match rule in the ruleset, but that > uses tables for a big chunk of the traffic, including our monitoring station > that has a pretty high SNMP request rate. That system has a state table that > usually stabilizes between 15-20K sessions, with a session search rate of > around 10K. The states limit has been raised to 100000 and the frags to > 10000, but all other limits are set to default values.
you can increase that much more. the times where kmem was a very scarce ressource are long over. > However, the "match" > counter always states a rate between 199/200 per second. the counter has nothing to do with match rules. it is increased any time a rule matches, regardless of the type. > During some heavy > traffic period, we are getting some failures from the monitoring system and > the only thing that seems possibly out of health for the system is the match > counter rate. System processor and memory are fine and there is no other > noticeable impact, but clearly the monitoring tool is seeing an impact, as > it didn't reflect something this behavior before we implemented the PF > systems. you might hit some other limit, not necessarily pf. start with checking sysctl net.inet.ifq - in particular drops, and increase maxlen if you see it increasing. depending on how you monitor you might also run into the icmp err rate limit, play with the net.inet.icmp.errppslimit sysctl. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
