This section describes the TCP/IP tunable parameters.
Tunable Parameter |
For Information |
---|---|
Solaris Kernel Tunables | |
NFS Tunable Parameters | |
Network Cache and Accelerator (NCA) Tunable Parameters |
Chapter 5, Network Cache and Accelerator (NCA) Tunable Parameters |
You can set all of the tuning parameters described in this chapter with the ndd command, except for the following two parameters that can only be set in the /etc/system file:
Use the following syntax to set TCP/IP parameters with the ndd command.
# ndd -set driver parameter |
For example, the following ndd command disables IP forwarding.
# ndd -set /dev/ip ip_forwarding 0 |
For more information, see ndd(1M).
To set a TCP/IP parameter across system reboots, include the appropriate ndd command in a system startup script. Use the following guidelines to create a system startup script to include ndd commands:
Create a script in the /etc/init.d directory and create links to it in the /etc/rc2.d, /etc/rc1.d, and /etc/rcS.d directories.
The script should run between the existing S69inet and S72inetsvc scripts.
Name the script with the S70 or S71 prefix. Scripts with the same prefix are run in some sequential way so it doesn't matter if there is more than one script with the same prefix.
For more information on naming run control scripts, see the README file in the /etc/init.d directory.
For more information on creating a startup script, see “Run Control Scripts” in System Administration Guide: Basic Administration.
All of the TCP/IP parameters described in this section are checked to verify they fall in the parameter range, which is provided in each tunable section, except for the two parameters that can be set only in the /etc/system file described above. For more information, see the validation section for tcp_conn_hash_size and ipc_tcp_conn_hash_size.
Internet protocol and standard specifications are described in RFC documents. You can get copies of RFCs by using anonymous ftp to the sri-nic.arpa machine. Browse RFC topics by viewing the rfc-index.txt file at this site.
This section describes some of the IP tunable parameters.
Control the rate of IP in generating IPv4 or IPv6 ICMP error messages. IP generates only up to ip_icmp_err_burst IPv4 or IPv6 ICMP error messages in any ip_icmp_err_interval. This parameter protects IP from denial of service attacks. Set ip_icmp_err_interval to 0 to disable IP to generate IPv4 or IPv6 ICMP error messages.
100 milliseconds for ip_icmp_err_interval
10 for ip_icmp_err_burst
0 - 99,999 milliseconds for ip_icmp_err_interval
1 - 99,999 for ip_icmp_err_burst
Yes
Change the parameter values if you need a higher error message generation rate for diagnostic purposes.
Unstable
Control whether IP does IPv4 or IPv6 forwarding between interfaces. See also xxx:ip_forwarding below.
0 (disabled)
0 (disabled), 1 (enabled)
Yes
If IP forwarding is needed, enable it.
Unstable
Enables IPv4 forwarding for a particular xxx interface. The exact name of the parameter is interface-name:ip_forwarding. For example, two interfaces are hme0 and hme1. Their corresponding parameter names are:
hme0:ip_forwarding and hme1:ip_forwarding
0 (disabled)
0 (disabled), 1 (enabled)
Yes
If you need IPv4 forwarding, use this parameter to enable forwarding on a per-interface basis.
Unstable
Control whether IPv4 or IPv6 responds to broadcast ICMPv4 echo request or multicast ICMPv6 echo request.
1 (enabled)
0 (disabled), 1 (enabled)
Yes
If you do not want this behavior for security reasons, disable it.
Unstable
Control whether IPv4 or IPv6 sends out ICMPv4 or ICMPv6 redirect messages. See also ip_forwarding and ip6_forwarding.
1 (enabled)
0 (disabled), 1 (enabled)
Yes
If you do not want this behavior for security reasons, disable it.
Unstable
Control whether IPv4 or IPv6 forwards packets with source IPv4 routing options or IPv6 routing headers. See also ip_forwarding and ip6_forwarding.
1 (enabled)
0 (disabled), 1 (enabled)
Yes
If you do not want this behavior for security reasons, disable it.
Unstable
The maximum number of logical interfaces associated with a real interface.
256
1 to 8192
Yes
Do not change the value. If more logical interfaces are required, increase the value, but recognize that this change might have a negative impact on IP's performance.
Unstable
Determine whether a packet arriving on a non-forwarding interface can be accepted for an IP address that is not explicitly configured on that interface. If ip_forwarding is enabled, or xxx:ip_forwarding for the appropriate interfaces is enabled, then this parameter is ignored, because the packet is actually forwarded.
Refer to RFC 1122 3.3.4.2.
0 (loose multihoming)
0 = Off (loose multihoming)
1 = On (strict multihoming)
Yes
If a machine has interfaces that cross strict networking domains (for example, a firewall or a VPN node), set this variable to 1.
Unstable
This parameter enables the network stack to send more than one packet at one time to the network device driver during transmission.
Enabling this parameter reduces the per-packet processing costs by improving the host CPU utilization and/or network throughput.
The multidata transmit (MDT) feature is only effective for device drivers that support this feature.
The following parameter must be enabled in the /etc/system file to use the MDT parameter:
set ip:ip_use_dl_cap = 0x1
Disabled
0 (disabled), 1 (enabled)
Yes
This feature can be enabled at any time to allow for improved system performance with the following cautions:
Enabling this feature might change the appearance of any packets between the IP layer and the DLPI provider. So, any third-party STREAMS module that is dynamically inserted between the IP layer and the DLPI provider by using ifconfig's modinsert feature, which doesn't understand the MDT STREAMS data type, might not work.
Modules that are inserted between the IP and the DLPI provider with the autopush(1m) mechanism might not work as well.
Keep this feature disabled when a STREAMS module is not MDT aware. For example, the public domain utilities such as ipfilter, Checkpoint Firewall-1, and so on, are not MDT aware.
Unstable
Changing the following parameters is not recommended unless there are extenuating circumstances that are described with each parameter.
The interval in milliseconds when IP flushes the path maximum transfer unit (PMTU) discovery information, and tries to rediscover PMTU.
Refer to RFC 1191 on PMTU discovery.
10 minutes
5 seconds to 277 hours
Yes
Do not change this value.
Unstable
When IPv4 or IPv6 sends an ICMPv4 or ICMPv6 error message, it includes the IP header of the packet that causes the error message. This parameter controls how many extra bytes of the packet beyond the IPv4 or IPv6 header to be included in the ICMPv4 or ICMPv6 error message.
64 bytes
8 to 65,536 bytes
Yes
Do not change the value. Including more information in an ICMP error message might help in diagnosing network problems. If this feature is needed, increase the value.
Unstable
The time-out value for TCP delayed acknowledgment (ACK) timer in milliseconds for hosts that are not directly connected.
Refer to RFC 1122, 4.2.3.2.
100 milliseconds
1 millisecond to 1 minute
Yes
Do not increase this value to more than 500 milliseconds.
If in some circumstances, slow network links (less than 57.6 Kbps) with greater than 512 bytes maximum segment size (MSS) when the interval is short for receiving more than one TCP segment, increase the value.
Unstable
The time-out value for TCP delayed acknowledgment (ACK) timer in milliseconds for hosts that are directly connected.
Refer to RFC 1122, 4.2.3.2.
50 milliseconds
1 millisecond to 1 minute
Yes
Do not increase this value to more than 500 milliseconds.
If in some circumstances, slow network links (less than 57.6 Kbps) with greater than 512 bytes maximum segment size (MSS) and the interval is short for receiving more than one TCP segment, increase the value.
Unstable
The maximum number of TCP segments (in units of maximum segment size MSS for individual connections) received from remote destinations (not directly connected) before an acknowledgment (ACK) is generated. If set to 0 or 1, it means no delayed ACKs, assuming all segments are 1 MSS long. The actual number is dynamically calculated for each connection. The value is the default maximum.
2
0 to 16
Yes
Do not change the value. In some circumstances, when the network traffic becomes very bursty because of the delayed ACK effect, decrease the value. Do not decrease this value below 2.
Unstable
The maximum number of TCP segments (in units of maximum segment size MSS for individual connections) received from directly connected destinations before an acknowledgment (ACK) is generated. If set to 0 or 1, it means no delayed ACKs, assuming all segments are 1 MSS long. The actual number is dynamically calculated for each connection. The value is the default maximum.
8
0 to 16
Yes
Do not change the value. In some circumstances, when the network traffic becomes very bursty because of the delayed ACK effect, decrease the value. Do not decrease this value below 2.
Unstable
If set to 1, TCP always sends SYN segment with the window scale option, even if the option value is 0. Note that if TCP receives a SYN segment with the window scale option, even if the parameter is set to 0, TCP responds with a SYN segment with the window scale option, and the option value is set according to the receive window size.
Refer to RFC 1323 for the window scale option.
0 (disabled)
0 (disabled), 1 (enabled)
Yes
If you want the window scale option in a high-speed network configuration, enable it.
Unstable
If set to 1, TCP always sends SYN segment with the timestamp option. Note that if TCP receives a SYN segment with the timestamp option, TCP responds with a SYN segment with the timestamp option even if the parameter is set to 0.
0 (disabled)
0 (disabled), 1 (enabled)
Yes
In summary, if an accurate measurement of round trip time (RTT) and TCP sequence number wraparound is a problem, enable it.
Refer to RFC 1323 for more reasons to enable this option.
Unstable
The default send window size in bytes. Refer to the following discussion of per-route metrics for setting a different value on a per route basis. See tcp_max_buf also.
49,152
4096 to 1,073,741,824
Yes
Note that this is the default value. An application can use setsockopt(3XNET) SO_SNDBUF to change the individual connection's send buffer.
Unstable
The default receive window size in bytes. Refer to the following discussion of per-route metrics for setting a different value on a per-route basis. See tcp_recv_hiwat_minmss and tcp_max_buf also.
49,152
2048 to 1,073,741,824
Yes
Note that this is the default value. An application can use setsockopt(3XNET) SO_RCVBUF to change the individual connection's receive buffer.
Unstable
The maximum buffer size in bytes. It controls how large the send and receive buffers are set to by an application using setsockopt(3XNET).
1,048,576
8192 to 1,073,741,824
Yes
If TCP connections are being made in a high-speed network environment, increase the value to match the network link speed.
Unstable
The maximum value of TCP congestion window (cwnd) in bytes.
For more information on TCP congestion window, refer to RFC 1122 and RFC 2581.
1,048,576
128 to 1,073,741,824
Yes
This is the maximum value a TCP cwnd can grow to. Note that even if an application uses setsockopt(3XNET) to change the window size to a value higher than tcp_cwnd_max, the actual window used can never grow beyond tcp_cwnd_max. Thus, tcp_max_buf should be greater than tcp_cwnd_max in general.
Unstable
The maximum initial congestion window (cwnd) size in MSS of a TCP connection.
Refer to RFC 2414 on how initial congestion window size is calculated.
4
1 to 4
Yes
Do not change the value.
If the initial cwnd size causes network congestion under special circumstances, decrease the value.
Unstable
The congestion window size in MSS of a TCP connection after it has been idled (no segment received) for a period of one retransmission timeout (RTO).
Refer to RFC 2414 for the calculation.
4
1 to 16,384
Yes
For more information, see tcp_slow_start_initial.
Unstable
If set to 2, TCP always sends SYN segment with the selective acknowledgment (SACK) permitted option. If TCP receives a SYN segment with a SACK-permitted option and this parameter is set to 1, TCP responds with a SACK-permitted option. If the parameter is set to 0, TCP does not send a SACK-permitted option, regardless of whether the incoming segment contains the SACK permitted option or not.
Refer to RFC 2018 for information on the SACK option.
2 (active enabled)
0 (disabled), 1 (passive enabled), 2 (active enabled)
Yes
SACK processing can improve TCP retransmission performance so it should be actively enabled. If, in some circumstances, the other side can be confused with the SACK option actively enabled, set the value to 1 so that SACK processing is enabled only when incoming connections allow SACK processing.
Unstable
If set to 0, TCP does not reverse the IP source routing option for incoming connections for security reasons. If set to 1, TCP does the normal reverse source routing.
0 (disabled)
0 (disabled), 1 (enabled)
Yes
If IP source routing is needed for diagnostic purposes, enable it.
Unstable
The time in milliseconds a TCP connection stays in TIME-WAIT state.
For more information, refer to RFC 1122, 4.2.2.13.
60,000 (60 seconds)
1 second to 10 minutes
Yes
Do not set the value lower than 60 seconds.
For more information, refer to RFC 1122, 4.2.2.13.
Unstable
Controls Explicit Congestion Notification (ECN) support.
If this parameter is set to 0, TCP does not negotiate with a peer that TCP supports the ECN mechanism.
If this parameter is set to 1 when initiating a connection, TCP does not tell a peer that TCP supports the ECN mechanism.
However, TCP tells a peer that it supports the ECN mechanism when accepting a new incoming connection request, if the peer indicates that the peer supports the ECN mechanism in the SYN segment.
If this parameter is set to 2, in addition to negotiating with a peer on the ECN mechanism when accepting connections, TCP indicates in the outgoing SYN segment that it supports the ECN mechanism when TCP makes active outgoing connections.
1 (passive enabled)
0 (disabled), 1 (passive enabled), 2 (active enabled)
Yes
ECN can help TCP in handling congestion control better. However, there are existing TCP implementations, firewalls, NATs, and other network devices that are confused by this mechanism. These devices do not comply to the IETF standard.
Because of these devices, the default value of this parameter is set to 1. In rare cases, passive enabling can still cause problems. Set the parameter to 0 only if absolutely necessary.
Unstable
The default maximum number of pending TCP connections for a TCP listener waiting to be accepted by accept(3SOCKET). See also tcp_conn_req_max_q0.
128
1 to 4,294,967,296
Yes
For applications such as web servers that might receive several connection requests, the default value might be increased to match the incoming rate.
Do not increase the parameter to a very large value. The pending TCP connections can consume excessive memory. And if an application is not fast enough to handle that many connection requests in a timely fashion because the number of pending TCP connections is too large, new incoming requests might be denied.
Note that increasing tcp_conn_req_max_q does not mean that applications can have that many pending TCP connections. Applications can use listen(3SOCKET) to change the maximum number of pending TCP connections for each socket. This parameter is the maximum an application can use listen() to set the number to. This means that even if this parameter is set to a very large value, the actual maximum number for a socket might be much less than tcp_conn_req_max_q, depending on the value used in listen().
Unstable
The default maximum number of incomplete (three-way handshake not yet finished) pending TCP connections for a TCP listener.
For more information on TCP three-way handshake, refer to RFC 793. See also tcp_conn_req_max_q.
1024
0 to 4,294,967,296
Yes
For applications, such as web servers that might receive excessive connection requests, you can increase the default value to match the incoming rate.
The following explains the relationship between tcp_conn_req_max_q0 and the maximum number of pending connections for each socket.
When a connection request is received, TCP first checks if the number of pending TCP connections (three-way handshake is done) waiting to be accepted exceeds the maximum (N) for the listener. If the connections are excessive, the request is denied. If the number of connections is allowable, then TCP checks if the number of incomplete pending TCP connections exceeds the sum of N and tcp_conn_req_max_q0. If it does not, the request is accepted. Otherwise, the oldest incomplete pending TCP request is dropped.
Unstable
For information, see tcp_conn_req_max_q0.
The default minimum value of the maximum number of pending TCP connection requests for a listener waiting to be accepted. This is the lowest maximum value of listen(3SOCKET) an application can use.
1
1 to 1024
Yes
This can be a solution for applications that use listen(3SOCKET) to set the maximum number of pending TCP connections to a value too low. Increase the value to match the incoming connection request rate.
Unstable
These parameters can be set only in the /etc/system file. After the file is modified, reboot the system.
The following entry sets tcp_conn_hash_size:
set tcp:tcp_conn_hash_size=1024 |
Controls the hash table size in the TCP module for all TCP connections.
Signed integer
512
512 to 1,073,741,824
The value should be a power of 2.
No. The parameter can only be changed at boot time.
If you set the parameter to a value that is not a power of 2, it is rounded up to the nearest power of 2.
If the system consistently has tens of thousands of TCP connections, increase the value accordingly. With the default value, TCP performs well up to a few thousand active connections. Note that increasing the hash table size means more memory consumption so set an appropriate value to avoid wasting memory unnecessarily.
Unstable
Controls the hash table size in an IP module for all active (in ESTABLISHED state) TCP connections.
Unsigned integer
512
512 to 2,147,483,648
It should be a power of two.
No. This parameter can only be changed at boot time.
If you set the parameter to a value that is not a power of 2, it is rounded up to the nearest power of two.
If the system consistently has tens of thousands of active TCP connections, increase the value accordingly. With the default value, the system performs well up to a few thousand active connections. Note that increasing the hash table size means more memory consumption so set an appropriate value to avoid wasting memory unnecessarily.
Unstable
Changing the following parameters is not recommended unless there are extenuating circumstances that are described with each parameter.
The default total retransmission timeout value for a TCP connection in milliseconds. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
For TCP retransmission timeout (RTO) calculation, refer to RFC 1122, 4.2.3. See also tcp_rexmit_interval_max.
8 minutes
500 millisecond to 1193 hours
Yes
Do not change this value. See tcp_rexmit_interval_max for exceptions.
Unstable
The default initial retransmission timeout (RTO) value for a TCP connection in milliseconds. Refer to the following discussion of per route metrics for setting a different value on a per-route basis.
3 seconds
1 millisecond to 20 seconds
Yes
Do not change this value. Lowering the value can result in unnecessary retransmissions.
Unstable
The default maximum retransmission timeout value (RTO) in milliseconds. The calculated RTO for all TCP connections cannot exceed this value. See also tcp_ip_abort_interval.
60 seconds
1 millisecond to 2 hours
Yes
Do not change the value in a normal network environment.
If in some special circumstances, the round trip time (RTT) for a connection is in the order of 10 seconds, you can change the value to a higher value. If you change this value, you should also change the tcp_ip_abort_interval parameter to match it. Change the value of tcp_ip_abort_interval to at least four times the value of tcp_rexmit_interval_max.
Unstable
The default minimum retransmission time-out (RTO) value in milliseconds. The calculated RTO for all TCP connections cannot be lower than this value. See also tcp_rexmit_interval_max.
400 milliseconds
1 millisecond to 20 seconds
Yes
Do not change the value in a normal network environment.
TCP's RTO calculation should be able to cope with most RTT fluctuations. If in some very special circumstances such that the round trip time (RTT) for a connection is in the order of 10 seconds, change to a higher value. If you change this value, you should change the tcp_rexmit_interval_max parameter to match it. You should change the value of tcp_rexmit_interval_max to at least eight times the value of tcp_rexmit_interval_min.
Unstable
A constant added to the calculated retransmission time-out value (RTO) in milliseconds.
0 milliseconds
0 to 2 hours
Yes
Do not change the value.
When the RTO calculation fails to obtain a good value for a connection in some circumstances, you can change this value to avoid unnecessary retransmissions.
Unstable
If this parameter is set to 1, and the window scale option is enabled for a connection, TCP also enables the timestamp option for that connection.
1 (enabled)
0 (disabled), 1 (enabled)
Yes
Do not change this value. In general, when TCP is used in high-speed network, protection against sequence number wraparound is essential, thus you need the timestamp option.
Unstable
Controls the default minimum receive window size. The minimum is tcp_recv_hiwat_minmss times the size of maximum segment size (MSS) of a connection.
4
1 to 65,536
Yes
Do not change the value. If changing it is necessary, do not change the value lower than 4.
Unstable
If set to 1, protocol control blocks of TCP connections in TIME-WAIT state are compressed to reduce memory usage. If set to 0, no compression is done. See tcp_time_wait_interval also.
1 (enabled)
0 (disabled), 1 (enabled)
Yes
Do not turn off the compression mechanism.
Unstable
This section describes some of the UDP tunable parameters.
The default maximum UDP socket datagram size in bytes. For more information, see udp_max_buf.
8192 bytes
4096 to 65,536
Yes
Note that an application can use setsockopt(3XNET) SO_SNDBUF to change the size for an individual socket. In general, you do not need to change the default value.
Unstable
The default maximum UDP socket receive buffer size in bytes. For more information, see udp_max_buf.
8192 bytes
4096 to 65,536
Yes
Note that an application can use setsockopt(3XNET) SO_RCVBUF to change the size for an individual socket. In general, you do not need to change the default value.
Unstable
Changing the following parameters is not recommended unless there are extenuating circumstances that are described with each parameter.
Controls how large send and receive buffers (in bytes) can be for a UDP socket.
262,144 bytes
65,536 to 1,073,741,824
Yes
Do not change the value. If this parameter is set to a very large value, UDP socket applications can consume too much memory.
Unstable
This section describes an IPQoS tunable parameter.
Enables or disables IPQoS processing in any of the following callout positions: forward outbound, forward inbound, local outbound, and local inbound. This parameter is a bitmask as follows:
Not Used |
Not Used |
Not Used |
Not Used |
Forward Outbound |
Forward Inbound |
Local Outbound |
Local Inbound |
---|---|---|---|---|---|---|---|
X |
X |
X |
X |
0 |
0 |
0 |
0 |
A 1 in any of the position masks or disables IPQoS processing in that particular callout position. For example, a value of 0x01 disables IPQoS processing for all the local inbound packets.
The default value is 0, meaning that IPQoS processing is enabled in all the callout positions.
0 (0x00) to 15 (0x0F). A value of 15 indicates that IPQoS processing is disabled in all the callout positions.
Yes
Change this parameter if you want to enable or disable IPQoS processing in any of the callout positions.
Unstable
Starting in the Solaris 8 release, you can use the per-route metrics to associate some properties with IPv4 and IPv6 routing table entries.
For example, a system has two different network interfaces, fast ethernet interface and gigabit ethernet interface. The system default tcp_recv_hiwat is 24,576 bytes. This default is sufficient for the fast ethernet interface, but may not be sufficient for the gigabit ethernet interface.
Instead of increasing the system's default tcp_recv_hiwat, you can associate a different default TCP receive window size to the gigabit ethernet interface routing entry. By making this association, all TCP connections going through the route will have the increased receive window size.
Assuming IPv4, the following is in the routing table (netstat -rn).
192.123.123.0 192.123.123.4 U 1 4 hme0 192.123.124.0 192.123.124.4 U 1 4 ge0 default 192.123.123.1 UG 1 8 |
Do the following:
# route change -net 192.123.124.0 -recvpipe x |
This means all connections going to the 192.123.124.0 network, which is on the ge0 link, use the receive buffer size x, instead of the default 24567 receive window size.
If the destination is in the a.b.c.d network, and there is no specific routing entry for that network, you can add a prefix route to that network and change the metric. For example:
# route add -net a.b.c.d 192.123.123.1 -netmask w.x.y.z # route change -net a.b.c.d -recvpipe y |
Note that the prefix route's gateway is the default router. Then all connections going to that network use receive buffer size y. If you have more than one interface, use the -ifp argument to specify which interface to use. This way, you can control which interface to use for specific destinations. To verify the metric, use the route(1M) get command.