Date: Fri, 31 Mar 2006 10:21:23 -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: <442D48F3.2020307@xecu.net> In-Reply-To: <000001c654d1$06bc4e60$0a00a8c0@thebeast>
index | next in thread | previous in thread | raw e-mail
Greg Hennessy wrote: >>I thought the most current recommendations were not to use >>polling? I thought this was something handled by most new hardware? >> >> > >I would use polling in any situation with the likelyhood of a high packet >rate, its integrated directly in the em NIC drivers as of 6.x and works a >treat through ifconfig. > > > I will implement polling and see if it helps. >>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. >> >> > >Hmmm, that sounds like a policy issue, 5.4 and em's iperf at > 900 meg/sec. > >What speed processor is driving this ? I assume you're using PCI-X >everywhere. > > > 2 of the nics are onboard, however the quad-port intel card is PCI-X. This is a 3.0Ghz pentium 4. >>I have switched this back he 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. >> >> > >Hmmm, that sounds more and more like a state mismatch issue. > >What is your default block rule catching ? It should give you an idea pretty >quick regarding state mismatches due to overlapping rules. > >I assume your 1st rule is > >block log all > >If not, it should be. > > > The first rule is block log all. I put the http rules right after that rule, or I lose connections. The packets are not being logged as blocked. The just never show up on the internal nic. I can make this a bi-direction rule instead of keep state and it still drops traffic if I move it down in the list. If I leave it where it is, and make it a keep state rule, it drops the connections also. >>>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? >> >> > >Definitely, Daniel H has recently described the reasons why creating tcp >state on anything other than S/SA is a bad idea, especially with TCP window >scaling. > > > Is there a link to this information, or has it recently been added to the documentation? I would like to read the reasoning behind this. >>I have read many of the >>examples and docs, and it appears this is done both ways >>depending on where you read it. >> >> > >Personally I would use flags S/SA for all stateful tcp rules. > > > >>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. >> >> > >It may be worth using something like cricket to track the amount of state >table entries. > > > At peak times, the state table grows as large as 17000 states or so. At slow times, the table is in the 3000 - 5000 range. While testing last night, it was at the lower range. The state table size doesn't seem to affect the http connection drops. >>>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. >> >> > >If you havent done so already, start using tags in conjunction with generic >egress rules on each interface. This will reduce the rulebase in size a lot. > > Generic egress rules are a little difficult because I'm trying to do traffic shaping of certain traffic. A side note, the machine is not doing any NAT. Tagging seems like it would require more overhead than what the firewall is doing already. I'm no developer, so I don't know the code involved, so I could definitely be wrong about this. Since more manageable rulesets were brought up, does the optimizer really do anything, or is that just asking for trouble? Chrishome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442D48F3.2020307>