Tighten the TCP / IP nuts on Solaris
Good afternoon, respected users, despite the tendency of the fall of Oracle in the eyes of system engineers and customer companies. The operating system, now Oracle Solaris continues to live and delight our eyes.
Recently I faced the issue of optimizing some parameters of the TCP / IP stack. This topic seemed interesting to me, it may seem to many already beaten, and it will introduce someone to new interesting moments of customization. So, let's begin…
To begin with, we consider two parameters like tcp_conn_req_max_q and tcp_conn_req_max_q0 , why they are needed at all, what values for these parameters are the most suitable.
In simple terms, these parameters are responsible for the maximum number of requests for an IP address and a port that will be processed by the server.
tcp_conn_req_max_q is the maximum number of incoming connections that will be processed by the port.
tcp_conn_req_max_q0 is the maximum number of half-open TCP sessions that can exist on a port.
These parameters on Solaris allow the administrator, in order to block SYN packets, to prevent “denial of service” attacks in DOS progenority.
The default value for tcp_conn_req_max_q on Solaris is only 128, and for tcp_conn_req_max_q0 1024. These parameters are in principle sufficient for a server serving a small number of clients, but if the server expects a greater number of hits than specified by default, this will significantly spoil the nerves of the system administrator. From the beginning, it looks like this.
When the time comes to change these parameters, in fact, it is quite simple to determine if the number of dropped packets goes off-scale, then the time has come. How to determine this number, we use the usual sample:
')
In my case, there are zeros here, since the test server cannot show the change in values. But the scheme is this: if the value of tcpListenDrop is not zero, increase tcp_conn_req_max_q, and if tcpListenDropQ0 is non-zero, respectively, increase the value of the tcp_conn_req_max_q0 parameter.
But, there is one BUT, if you immediately increase tcp_conn_req_max_q immediately, then it will naturally be vulnerable to DOS using SYN packets. Just for this we need the second parameter, which is ideally designed to prevent such cases. The second parameter is responsible for the sessions that will be queued on the server after receiving the SYN packet. Unfortunately, it also cannot be increased dimensionlessly, as in the case of slow application work, clients will get into the queue and remain there, without connecting to the server.
Any changes to these values are easily carried out using the ndd command, as an example, I will give the values of one of the heavily loaded servers, these parameters can be used in the work:
In conclusion, I would like to say about these parameters that it is necessary to relate to changes in these parameters with due scrupulousness and not to change them unnecessarily.
PS If anyone has an interest in other parameters, in the next article it will be possible to describe them. Thanks for attention.
Recently I faced the issue of optimizing some parameters of the TCP / IP stack. This topic seemed interesting to me, it may seem to many already beaten, and it will introduce someone to new interesting moments of customization. So, let's begin…
To begin with, we consider two parameters like tcp_conn_req_max_q and tcp_conn_req_max_q0 , why they are needed at all, what values for these parameters are the most suitable.
In simple terms, these parameters are responsible for the maximum number of requests for an IP address and a port that will be processed by the server.
tcp_conn_req_max_q is the maximum number of incoming connections that will be processed by the port.
tcp_conn_req_max_q0 is the maximum number of half-open TCP sessions that can exist on a port.
These parameters on Solaris allow the administrator, in order to block SYN packets, to prevent “denial of service” attacks in DOS progenority.
The default value for tcp_conn_req_max_q on Solaris is only 128, and for tcp_conn_req_max_q0 1024. These parameters are in principle sufficient for a server serving a small number of clients, but if the server expects a greater number of hits than specified by default, this will significantly spoil the nerves of the system administrator. From the beginning, it looks like this.
root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q 128 root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q0 1024 When the time comes to change these parameters, in fact, it is quite simple to determine if the number of dropped packets goes off-scale, then the time has come. How to determine this number, we use the usual sample:
root@T1000-spare # netstat -s | fgrep -i listendrop tcpListenDrop = 0 tcpListenDropQ0 = 0 sctpListenDrop = 0 sctpInClosed = 0 ')
In my case, there are zeros here, since the test server cannot show the change in values. But the scheme is this: if the value of tcpListenDrop is not zero, increase tcp_conn_req_max_q, and if tcpListenDropQ0 is non-zero, respectively, increase the value of the tcp_conn_req_max_q0 parameter.
But, there is one BUT, if you immediately increase tcp_conn_req_max_q immediately, then it will naturally be vulnerable to DOS using SYN packets. Just for this we need the second parameter, which is ideally designed to prevent such cases. The second parameter is responsible for the sessions that will be queued on the server after receiving the SYN packet. Unfortunately, it also cannot be increased dimensionlessly, as in the case of slow application work, clients will get into the queue and remain there, without connecting to the server.
Any changes to these values are easily carried out using the ndd command, as an example, I will give the values of one of the heavily loaded servers, these parameters can be used in the work:
# ndd -set /dev/tcp tcp_conn_req_max_q 16384 <==== # ndd -set /dev/tcp tcp_conn_req_max_q0 16384 <==== # ndd -set /dev/tcp tcp_max_buf 4194304 # ndd -set /dev/tcp tcp_cwnd_max 2097152 # ndd -set /dev/tcp tcp_recv_hiwat 400000 # ndd -set /dev/tcp tcp_xmit_hiwat 400000 In conclusion, I would like to say about these parameters that it is necessary to relate to changes in these parameters with due scrupulousness and not to change them unnecessarily.
PS If anyone has an interest in other parameters, in the next article it will be possible to describe them. Thanks for attention.
Source: https://habr.com/ru/post/137956/
All Articles