On Thu, May 10, 2007 at 02:31:54AM -0400, Daniel Ouellet wrote: > Ted Unangst wrote: > >On 5/9/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote: > >>I try to stay safe in my choices and comments are welcome, but I have to > >>point out as well that ALL the values below needs to be changes to that > >>new value to get working well. If even only one of them is not at the > >>level below, the results in the tests start to be affected pretty bad at > >>times. > >>net.bpf.bufsize=524288 > >>net.inet.ip.redirect=0 > > > >never mind the rest, but these two really make no sense. none. > > Make no sense in the test and improving results, or make no sense in > setting them as such here? > > net.inet.ip.redirect=0 > > Is to disable ICMP routing redirects. Otherwise, your system could have > its routing table misadjusted by an attacker. Wouldn't be wise to do so? > May be if PF is turn on, then there is no reason for this, but with PF > ON, I get drop and need to address that. Didn't pursue it yet as dead > however. >
net.inet.ip.redirect has only an effect if you enable net.inet.ip.forwarding. As you are running a server and not a router I doubt this is the case. Additionally net.inet.ip.redirect does not modify the routing table. Your are probably looking at net.inet.icmp.rediraccept. > As for the net.bpf.bufsize, I am looking again in my notes and tests, > it's use for Berkeley Packet Filter (BPF), to maintains an internal > kernel buffer for storing packets received off the wire. > > Yes in that case it make sense not to have that here. I redid the tests > with the default value and yes you are right! This one is wrong here. > May be lack of sleep. (;> Thanks for correcting me! > > I also have the revise my statement on the net.inet.ip.portfirst=32768 > effect. In a series of new tests, it doesn't have the impact noted the > first test runs. So, I would keep it as default value as well now. May > be it was when PF was enable that I have more of an impact then. But my > notes are not clear on that specific one. > With many shortliving connections you have a lot of sockets in TIME_WAIT. Because you are testing from one host only you start to hit these entries more and more often this often results in a retry from the client. Additionally by filling all available ports the port allocation algorithm is starting to get slower but that's a problem that you will only see on the host :) The accept behaviour of OpenBSD should be fine. > Anything else you see that may be questionable in what I sent? I am > doing more tests with different hardware to be sure it's all sane value > in the end. > > Other wise many thanks for having taken the time to look it over and > give me your feedback on it! > I think there are a few knobs that you should reconsider. I will write an other mail about that. -- :wq Claudio
