Re: Loaded server or syn-flood?
On 15 Jan 2004 15:40 CET you wrote: TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I'm afraid we need morei info. What is the time interval between the messages, how long did it last? Were the IP numbers all different or not? Do you monitor load and sysstat on your server? If yes, what does it say? I dont really monitor the serverload as there was no need to do it before ... havn't really thought about it ... until now. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. Definitiley upgrade the kernel do 2.4.24, there are several security issues in .21 Ok. I've upgraded it to 2.4.24 now. I had the modprobe workaround enabled in my .21, didnt know there was so many security issues. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? Our production kernels are compiled with TCP SYN Cookie support, so the servers can survive a SYN flood as long as it doesn't max out the connection. Apart form that, tight monitoring of resource usage is necessary, to ensure the system can physically cope with the load. Best of luck and send more info if you seek a better advice. I've also enabled TCP SYN Cookie support now, let's see what happens. Thanks Christofer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Loaded server or syn-flood?
On 15 Jan 2004 15:40 CET you wrote: TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I'm afraid we need morei info. What is the time interval between the messages, how long did it last? Were the IP numbers all different or not? Do you monitor load and sysstat on your server? If yes, what does it say? I dont really monitor the serverload as there was no need to do it before ... havn't really thought about it ... until now. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. Definitiley upgrade the kernel do 2.4.24, there are several security issues in .21 Ok. I've upgraded it to 2.4.24 now. I had the modprobe workaround enabled in my .21, didnt know there was so many security issues. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? Our production kernels are compiled with TCP SYN Cookie support, so the servers can survive a SYN flood as long as it doesn't max out the connection. Apart form that, tight monitoring of resource usage is necessary, to ensure the system can physically cope with the load. Best of luck and send more info if you seek a better advice. I've also enabled TCP SYN Cookie support now, let's see what happens. Thanks Christofer
Re: Loaded server or syn-flood?
On Wed, 2004-01-14 at 23:50, Christofer Algotsson wrote: Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I'm afraid we need morei info. What is the time interval between the messages, how long did it last? Were the IP numbers all different or not? Do you monitor load and sysstat on your server? If yes, what does it say? I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... Yes, that's right, these are the two possibilities. The machine acts web-server (apache) and serves about 3,500,000 requests / week. Again, do you monitor load, sysstat (memory usage), sar/vmstat (disk activity)? The number doesn't say much, boils down to 5 req/s average, you need to know the tops. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. Definitiley upgrade the kernel do 2.4.24, there are several security issues in .21 As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? Our production kernels are compiled with TCP SYN Cookie support, so the servers can survive a SYN flood as long as it doesn't max out the connection. Apart form that, tight monitoring of resource usage is necessary, to ensure the system can physically cope with the load. Best of luck and send more info if you seek a better advice. -- Jan Kokoska -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Loaded server or syn-flood?
On Wed, 2004-01-14 at 23:50, Christofer Algotsson wrote: Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I'm afraid we need morei info. What is the time interval between the messages, how long did it last? Were the IP numbers all different or not? Do you monitor load and sysstat on your server? If yes, what does it say? I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... Yes, that's right, these are the two possibilities. The machine acts web-server (apache) and serves about 3,500,000 requests / week. Again, do you monitor load, sysstat (memory usage), sar/vmstat (disk activity)? The number doesn't say much, boils down to 5 req/s average, you need to know the tops. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. Definitiley upgrade the kernel do 2.4.24, there are several security issues in .21 As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? Our production kernels are compiled with TCP SYN Cookie support, so the servers can survive a SYN flood as long as it doesn't max out the connection. Apart form that, tight monitoring of resource usage is necessary, to ensure the system can physically cope with the load. Best of luck and send more info if you seek a better advice. -- Jan Kokoska
Loaded server or syn-flood?
Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... The machine acts web-server (apache) and serves about 3,500,000 requests / week. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? -- __ Yours sincerely, Christofer Algotsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Loaded server or syn-flood?
Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... The machine acts web-server (apache) and serves about 3,500,000 requests / week. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? -- __ Yours sincerely, Christofer Algotsson
