Helpforce provides free 24/7 online technical support

I have received this error on a port listened to by a Squid server. Is this warning issued prior to reaching the point where pending TCP requests would have been dropped? And if that point is reached, would the counter for tcpListenDropQ0 shown in netstat be greater than 0? Mine is at 0. Thanks.

-- - Kyle

15/05/2018 14:54 - Kyle Tucker wrote: Hi Kyle It sounds like maybe the box is getting hammered - Is it really busy? There are steps you can take to tune the stack on Solaris boxes, you can make changes to set numerous variables in order to increase throughput.

Below is a script I use when setting up web servers (Sol 10) which seems to increase throughput - YMMV of course, and I wouldn't blindly apply the script, take some time to work through it and identify if it would be useful to you. Some features may not work on older Solaris versions, again YMMV.

http://docs.sun.com/app/docs?q=tunable+parameters+solaris is very useful.

#!/bin/sh # # S70stacktune # v 1.22 25/2/2006 SamN # Tune TCP stack on busy Solaris 10 boxes.

fill () { awk '{leninput=length($($NF)); fill=63-leninput ; for (i=1; i< fill; i++) fillchar=fillchar. ; printf $($NF) fillchar}' } setparams () { VAL=`/usr/sbin/ndd -set $1 $2 $3` printf Value of $1 $2 is: | fill printf ${VAL} ($3) } # Set the tcp time wait interval printf Set the tcp time wait interval setparams /dev/tcp tcp_time_wait_interval 60000 # Speed up the flushing of half-closed connection in state FIN_WAIT_2 printf Flushing of half-closed connection in state FIN_WAIT_2 setparams /dev/tcp tcp_fin_wait_2_flush_interval 67500ms # Set the receive and transmit window sizes printf Set the receive and transmit window sizes setparams /dev/tcp tcp_xmit_hiwat 400000 setparams /dev/tcp tcp_recv_hiwat 400000 # Set number of half-open connections printf Set number of half-open connections setparams /dev/tcp tcp_conn_req_max_q0 102400 # Set number of simultaneous connections printf Set number of simultaneous connections setparams /dev/tcp tcp_conn_req_max_q 102400 # Set the maximum buffer size printf Set the maximum buffer size setparams /dev/tcp tcp_max_buf 4194304 # Set the tcp time wait interval printf Set the tcp time wait interval setparams /dev/tcp tcp_time_wait_interval 60000 # Set TCP connection abort interval printf Set TCP connection abort interval setparams /dev/tcp tcp_ip_abort_interval 60000 # Set congestion window size printf Set congestion window size setparams /dev/tcp tcp_cwnd_max 2097152 # Set TCP Keepalive Interval printf Set TCP Keepalive Interval setparams /dev/tcp tcp_keepalive_interval 60000 printf Ok, tuning complete

15/05/2018 14:54 - In article <4P8ig.14582$qD.954@newsfe1-gui.ntli.net>, Sam N <sun@unix.ms.nospam> writes: Right, and then I'd have thought netstat would have showed tcpListenDropQ0 > 0. The box had not been rebooted between the message and when I ran netstat. Maybe I'll set up a test box with a very low setting and see if I can get the error generated and get tcpListenDropQ0 incremented. Thanks.

-- - Kyle

15/05/2018 14:54 - Kyle Tucker wrote: As far as I'm aware the alert is generated when the box thinks it's under a SYN flood attack (and the unestablished connection queue becomes full).

/dev/tcp tcp_conn_req_max_q0 - unestablished connection queue (incomplete handshake) /dev/tcp tcp_conn_req_max_q - established connection queue Are two parameters that you can tune in order to increase the queue sizes.

http://www.informit.com/articles/article.asp?p=101138&seqNum=5&rl=1 has more info - it seems to be a pretty good article.

cheers Sam

15/05/2018 14:54 - Sam N <sun@unix.ms.nospam> wrote: I don't know how busy that particular box was at the time (no sar) and it's at a customer site, but will watch it more closely in the future.

[ script snipped ] This looks very helpful.

Yes, I read a good amount on docs.sun.com and Google groups when this occured. But I can't find a definitive answer to what actually occurs, if anything, when the error is issued and what increments the above counters in netstat. Any idea? Thanks.

-- - Kyle

eDiscover

Click the logo to go back to the main page

Search eDiscover

Categories