Skip site navigation (1)Skip section navigation (2)
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>
References:  <000001c654d1$06bc4e60$0a00a8c0@thebeast>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

Chris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442D48F3.2020307>