PF state limits and logs
Hello Recently I've had problems because my firewall (4.1-stable) has hit states limit. I was surprised when I found nothing in logs (debug urgent) . Is it intented or is it an oversight ? Regards Piotrek
Re: pf state limits
* Brian A. Seklecki [EMAIL PROTECTED] [2007-05-17 23:52]: Given a i386 kernel, assume I can toss as much RAM at the box as needed (I know this isn't the limitation, it's a kernel memory issue), what's the maximum I can set the state table size to? I have a couple Wild guess: The limitiation is the max value that the variable size of the counter can contain, followed secondly by physical memory. no, it is much much more complicated than that. If there was an easy, reliable way to calculate the max, we would have the kernel do the math and not export a user-settable limit. there is no better answer than try out. increase, fill state table. repeat until the box panics. than chose a limit smaller than that. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: pf state limits
Wild guess: The limitiation is the max value that the variable size of the counter can contain, followed secondly by physical memory. ~BAS On Mon, 5 Mar 2007, Bill Marquette wrote: I know this has come up in the past but I haven't been able to track down a definitive answer (I'm sure there's a reason why), so I'll ask the question again. Given a i386 kernel, assume I can toss as much RAM at the box as needed (I know this isn't the limitation, it's a kernel memory issue), what's the maximum I can set the state table size to? I have a couple boxes that are running around 200K states with the limit set at 256K. I expect that I will see a growth in that state table size as the traffic to the servers behind these machines increases during our peak season. I can tune the tcp.closed parameter a bit on the external rules as 75% of these states are fin_wait_2:fin_wait_2, but before I start messing with that I'd rather increase the state limit some more. I can also try adaptive timeouts on those rules, but I'm more than a little paranoid about having the system dynamically change timeout values. Any suggestions on what the max might be and how I can monitor the system to see where I'm at in relationship to the max (if there's no hard number, I'm guessing the number depends on hardware and other system options that affect kernel memory). --Bill l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ Guilty? Yeah. But he knows it. I mean, you're guilty. You just don't know it. So who's really in jail? ~James Maynard Keenan
pf state limits
I know this has come up in the past but I haven't been able to track down a definitive answer (I'm sure there's a reason why), so I'll ask the question again. Given a i386 kernel, assume I can toss as much RAM at the box as needed (I know this isn't the limitation, it's a kernel memory issue), what's the maximum I can set the state table size to? I have a couple boxes that are running around 200K states with the limit set at 256K. I expect that I will see a growth in that state table size as the traffic to the servers behind these machines increases during our peak season. I can tune the tcp.closed parameter a bit on the external rules as 75% of these states are fin_wait_2:fin_wait_2, but before I start messing with that I'd rather increase the state limit some more. I can also try adaptive timeouts on those rules, but I'm more than a little paranoid about having the system dynamically change timeout values. Any suggestions on what the max might be and how I can monitor the system to see where I'm at in relationship to the max (if there's no hard number, I'm guessing the number depends on hardware and other system options that affect kernel memory). --Bill
