Date: Fri, 31 Mar 2006 08:59:58 -0500 From: Christopher McGee <chris@xecu.net> To: Greg Hennessy <Greg.Hennessy@nviz.net> Cc: freebsd-pf@freebsd.org Subject: Re: Traffic mysteriously dropping Message-ID: <442D35DE.9060707@xecu.net> In-Reply-To: <000401c65498$d14b8f30$0a00a8c0@thebeast> References: <000401c65498$d14b8f30$0a00a8c0@thebeast>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Hennessy wrote: > > > >>These 2 problems, are making pf, virtually unusable for our >>firewall needs. Hopefully there is a fix for them. >> >> >> > >Have you tried to ifconfig polling for all the em interfaces ? > > I thought the most current recommendations were not to use polling? I thought this was something handled by most new hardware? >I have recently installed a PF system on 6.1 prerelease with 4 * em + 2 * >bge & 80 odd rules, it's not sweating @ ~600 meg/sec being thrown at it. >That's with ALTQ compiled in but not used in the policy at present. > > > Altq is compiled in on this machine also, however, when not being used, I see the same result. I've seen many stories of 600Meg/sec+, however, up until now, I have not been able to accomplish it. >Unless you are using synproxy I would suggest getting rid of set >state-policy if-bound and stick with the default of floating. > > > I have switched this back to the default. I get the same result. If I move the rule even 1 or 2 down in the list, traffic starts dropping on the http connections. I will leave it this way though. >Are all your stateful tcp rules using flags S/SA to establish state ? > > > Not all of the rules are stateful, but the ones that are just use the "keep state" directive, they are not using S/SA. Is this the recommended method? I have read many of the examples and docs, and it appears this is done both ways depending on where you read it. >Are you running out of state table entries ? > > >The default is 10k, tracking it with pfctl -si will tell you. > > > We have a lot of smtp traffic sometimes, so for those times, we have bumped up the state limit, however, at times like my testing last night, there were between 4000 and 5000 states, a few hundred at a time would be my testing. >With nearly 400 firewall rules, I would suggest that there's scope for >reviewing order and the judicious use of quick to trim the policy into >something more manageable. > > Well, this is something that was inherited, and therefore is taking much time to fix, however, the rules will be trimmed. I've already made extensive use of tables, and re-ordered/trimmed certain unnecessary things. That is an ongoing process and with it being a production box, it's hard to make any drastic changes. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442D35DE.9060707>