TCP/IP PSD/FAQ

1.0: TCP/IP

1.1: About TCP/IP

2.0: Debugging TCP/IP

2.1: netstat 
2.2: etherfind and snoop

3.0: Common How Tos

3.1.1: config Variables
3.1.2: in_proto.c Variables 
3.2: Information on ndd Network parameters and Variables in Solaris 2.
3.2.1: IP Variables
3.2.2: TCP Variables
3.2.3: UDP Variables
3.2.4: ARP Variables

4.0: Some Frequently Asked Questions

4.1: Miscellaneous Questions 
4.2: Questions on Ports 
4.3: netstat Questions 
4.4: Web Server TCP/IP Optimization

5.0: Patches

5.1: SunOS TCP/IP Patches
5.2: Solaris TCP/IP Patches

6.0: Known Bugs & RFEs

6.1: RFEs

7.0: References

7.1: Important Man Pages 
7.2: Sunsolve Documents 
7.2.1: FAQs 
7.2.2: Infodocs 
7.2.3: SRDBs;
7.3: Sun Educational Services 
7.4: Solaris Documentation 
7.5: Third Party Documentation 
7.6: RFCs

8.0:Supportability

9.0: Additional Support

This Tip Sheet documents a wide variety of information concerning TCP/IP. It is mainly concerned with information on the tuning options available in Sun TCP/IP, as well as a few of the most common questions. Unless you are doing really low level work with TCP/IP, this Tip Sheet probably will not be of too much use to you. However, if you are doing low level work, this Tip Sheet will give you some ideas on what you can do with Sun's TCP. A lot of the topics in this Tip Sheet fall under the category of Performance Tuning. This is an area that is normally not covered by SunService. Hopefully, this Tip Sheet will get you started tuning things on your own. If it is insufficient, you should consult Sections 8.0 and 9.0 for how to get help from Sun Consulting Services. 2.0 Debugging TCP-IP 

2.1: netstat 

 The netstat program may be used to examine a wide variety of network information. In its most basic form, when run without arguments, netstat will show currently active connections: # netstat TCP Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- localhost.32791 localhost.32796 8192 0 8148 0 CLOSE_WAIT psi.3139 sockem.listen 8760 0 8760 0 ESTABLISHE psi.login sun-soft.1020 4096 0 9112 0 ESTABLI The most important bits of information here are the local address (local name + local port), the remote address (remote name + remote port) and the State. In many cases, the port number is replaced by a port name, defined by the /etc/services file. The possible states are all defined in the netstat man page. Of particular note is the TIME_WAIT state connections will always wait in that state for a designated amount of time (called the 2MSL time) before the connection is totally shut down. This is to prevent new programs from reusing a port during a period in which packets destined for an older application might arrive there. netstat -a also shows information as above, but includes all server processes, which are usually waiting in a LISTEN state (netstat without options only lists active processess, not passively LISTENing processes). netstat is commonly used in debugging to examine network performance problems which may relate to programs getting stuck in certain states. This is done by examining the states noted in the netstat output above. There are a number of other uses for netstat: netstat -i will show interface information, netstat -p will show arp information and netstat -r will show routing information. 

2.2: etherfind and snoop  

You can use etherfind (SunOS) and snoop (Solaris) to examine every single packet which goes across the network. They can be useful if you are looking for retransmissions, duplicate ACKs, or other similar problems. The etherfind and snoop man pages explain how to use those utilities to examine the network. SunService also has a seperate Tip Sheet (the Miscellaneous Programs Tip Sheet) which outlines some basic uses of etherfind and snoop. 3.0 Common How Tos 

3.1: How to Tune Network Variables in SunOS  

3.1.1: config Variables 

 Four variables may be modified in the config file for your kernel (eg /sys/sun4c/conf/GENERIC). Each of these may be changed by adding a line as follows: options OPTIONNAME =value For example: options IPFORWARDING =-1 The legal options are: DIRECTED_BROADCAST Determines whether to forward broadcasts directed to a specific net or subnet, if that net or subnet is directly connected to the machine. The default value is 1 (True). IPFORWARDING Determines if the workstation will route packets. This variable can be one of three selections: -1 Never forward 0 Only forward when two or more interfaces are up 1 Always forward The default value is 0. IPSENDREDIRECTS Determines whether host should send ICMP redirects when it routes packets. The default value is 1 (True). SUBNETSARELOCAL Determines if remote subnets on the same network should be considered local. The default value is 1 (True). After making any of these changes, config the kernel, and remake it. 

3.1.2: in_proto.c Variables 

 Other Network variables may be modified under SunOS by modifying the file /sys/netinet/in_proto.c. These are each standard C declarations. After modifying them, the kernel must be rebuilt. tcp_default_mss Determines the Maximum Segment Size for nonlocal packets (ie, packets to be sent to different networks or subnets). The Definition of local may differ, depending on how SUBNETSARELOCAL is set. The default value for tcp_default_mss is 536 bytes. tcp_keepidle Determines how frequently to test if an idle connection is still alive. The default value is 2 hours. tcp_keepintvl Determines how frequently to check an idle connection, if the first check has failed. The default value is 75 seconds. tcp_keeplen Compatibility variable that must be set to 1 for BSD4.2 compatibility. The default value is 1. tcp_nodelack Determines whether ACKs can be delayed. Default is 0 (Allow ACKs to be delayed). A value of 1 will turn off delayed ACKs. tcp_recvspace Determines the maximum value of the TCP receive window. The default value is 4096 (4k). tcp_sendspace Determines the maximum value of the TCP transmit window. The default value is 4096 (4k). tcp_ttl Determines the default Time To Live for TCP packets. The default value is 60. udp_cksum Determines whether to checksum UDP packets. The default value is 0 (False). This should usually be changed to 1 (True) if you are having any troubles with UDP services (ie, NFS, NIS) udp_ttl Determines the default Time To Live for UDP packets. The default value is 60. udp_recvspace Determines the maximum value of the UDP receive window. The default value is 18000 bytes. udp_sendspace Determines the maximum value of the UDP transmit window. The default value is 9000 bytes. 

3.2: Information on ndd Network parameters and Variables in Solaris 2. 

 Most TCP, IP, UDP and ARP tuning in Solaris is done via the ndd command. You can list all of the appropriate variables by supplying ndd with the driver name and a ?, ie: %% ndd /dev/arp \? %% ndd /dev/ip \? %% ndd /dev/tcp \? %% ndd /dev/udp \? Note: Under Solaris 2.5 or higher, you will need to be root to display or set these variables. You can change ndd variables by supplying the -set option, the variable name, and the value, ie: %% ndd -set /dev/ip ip_forwarding 0 If you wish an ndd variable to get set upon every boot, you should put a line for it in the file /etc/rc2.d/S69inet: %% cat /etc/rc2.d/S69inet ... # # Set configurable parameters. # ndd -set /dev/tcp tcp_old_urp_interpretation 1 or a preferred method is to create a separate startup script. Once you have refined which parameters you require for individual drivers it is recommend that the complete 'ndd' commands are included in a new start-up script /etc/init.d/net-tune which is linked to /etc/rc2.d/S68net-tune. example: #!/sbin/sh # /etc/rc2.d/S68net-tune -> /etc/init.d/net-tune PATH=/usr/bin:/usr/sbin case "$1" in 'start') echo "Setting local Solaris kernel changes - ndd Tuning " ndd -set /dev/ip ip_path_mtu_discovery 0 ndd -set /dev/tcp tcp_rexmit_interval_max 60000 ndd -set /dev/tcp tcp_recv_hiwat 32768 ndd -set /dev/tcp tcp_xmit_hiwat 32768 ndd -set /dev/tcp tcp_slow_start_initial 2 'stop') echo "No kernel parameters changed." ;; *) echo "Usage: $0 {start|stop}" ;; esac exit 0 Many variables have two options: 1 (True) and 0 (False). Note: in all of the following examples, OS versions may differ, and can always be discovered by typing: # ndd device variable ie: # ndd /dev/ip ip_forwarding 0 WARNING concerning the ndd variables: ndd is/was not designed to be a general tuning mechanism for customers. Setting any parameters will affect your entire machine and always involves tradeoffs. In general, the defaults set by Solaris are optimal for most situations. They should be considered quite volatile, and might totally change from one release of Solaris to another.Only the variables that are the most useful, or the least likely to change, are listed below, but even these could be potentially modified in new releases of the OS. Unlisted variables, which can be viewed with the ndd command, should be considered even less static. Always make sure you understand what you are changing and for what reason. Make a comment in the startup script if you choose to add it permanently so that others know why this change was done. The parameters not listed are usually reserved for in-dept debugging and for developers. 

3.2.1: IP Variables 

 ip_addrs_per_if limit on IP addresses per interface The Number of multiple logical interfaces that can be associated with a physical network interface. (le0:0, le0:2 ... , le0:255,). 2.5.1 and 2.6 Default value = 256 ip_enable_group_ifs 2.6 parameter that enables ip load balancing over physical interfaces. see ifconfig 2.6 man page INTERFACE GROUPS " rotate source address selection when the source address is unspecified, and in the case of multiple physical interfaces in the same group, to scatter traffic across different IP addresses on a per-IP-destination basis. Default value is 0 (Default =1 before patch 105786-05) ip_forwarding Determines if the workstation will route packets. ( forward packets between interfaces) This variable can be one of three selections: 0 Never forward 1 Always forward 2 Only forward when two or more interfaces are up The default value is 2 on 2.4, 2.5 and 2.5.1 systems. if_forwarding value of 2 was removed in Solaris 2.6 /* RFC1122 Conformance */ see /etc/rc2.d/S69inet ip_forward_src_routed Determines whether to forward packets that are source routed, (packets which have a specific machine listed as part of route. setting to 0 prevents a router from generating source routed packets, or from participating as a source router. The default value is 1 ip_ire_status List current IREs (Internet Routing Entries). This is the cache of addresses ip is actually using . similar output version of " netstat -rvan " used for debugging ( Read Only ) ip_ire_cleanup_interval how long to keep a route that is not being used. This is the length of time that a specific route is allowed to exist without being used. The default is 30000 ms (30 seconds). ip_ire_flush_interval maxmimum length a specific route may be kept, even if it is being used. This is the period after which all specific routes are thrown away. The default is 1200000 ms (20 minutes). ip_path_mtu_discovery Determines whether to use the Path MTU Discovery algorithms, in order to prevent excessive packet fragmentation. The default value is 1 (True). see RFC 1191 Note: using FDDI , TR , ATM , on Solaris between networks with different MTU sizes, you may need to off ip path mtu discovery to enable fragmentation, if implementing routers that do not support RFC 1191. ex:# /usr/sbin/ndd -set /dev/ip ip_path_mtu_discovery 0 ip_send_redirects Determines whether the host should send ICMP redirects when it routes packets. The default value is 1 (True). ip_strict_dst_multihoming Determines whether to use Strict Destination Multihoming. If this variable is set to True, andip_forwarding is turned off, then the machine will not except packets destined for a different interface. see RFC1122 The default value is 0 

3.2.2: TCP Variables

tcp_close_wait_interval Despite the misleading name, this variable actually sets the time wait interval (the 2MSL value). The default value is 240000 ms (4 minutes). tcp_conn_req_max **replaced. This value is well-known as it normally needs to be increased for Web servers in older releases of Solaris 2 which sets the maximum size a listener's backlog. Sets maximum number of pending connection requests queued for a listening endpoint. It no longer exists in Solaris 2.6, or 2.5.1 w/patch 103582-12. **The change is part of a fix that prevents denial of service from SYN flood attacks. There are now two separate queues of partially complete connections instead of one. tcp_conn_req_max_q The maximum number of completed connections waiting to return from an accept call as soon as the right process gets some CPU time. # of conn reqs in SYN_RCVD - "fully-established" connections - those which have finished the 3-way handshake and are waiting to be picked up by an "accept()" call. (default value 128) tcp_conn_req_max_q0 The maximum number of connections with handshake incomplete. A SYN flood attack could only affect this queue, and a special algorithm makes sure that valid connections can still get through. "half-open" connections - those which have responded to a SYN request and are waiting for the final ack to come back to finish the 3-way handshake (default value 1024) tcp_keepalive_interval Determines how frequently to test if an unresponsive connection is still alive if the server application has KEEPALIVES enabled. see setsockopt SO_KEEPALIVE Probes are sent after tcp_keepalive_interval and probe again at tcp_rexmit_interval_max until tcp_ip_abort_interval, with no client response the connection is killed. The default value is 7200000 ms (2 hours as specified in rfc1122) tcp_ip_abort_cinterval Abort timeout at connect time. This is the 3-way handshake abort timer. The default value is 180000 (3 MIN) tcp_ip_abort_interval Abort interval used after connected (abort timeout for an established connection) This is the maximum time TCP retransmits will be tried for a connection in the ESTABLISHED state should be tried before a RESET segment is sent. Default 480000 (8*MINUTES) tcp_ip_notify_cinterval The timeout value when tcp is performing active open after which TCP notifies IP to find a new route Default 10000 (10 SEC) tcp_ip_notify_interval The timeout value for an ESTABLISHED connection after which TCP notifies IP to find a new route. Default 10000 (10 SEC) tcp_largest_anon_port Largest TCP port number that may be used for anonymous connections. The default value 65535 tcp_max_buf Specifies the maximum buffer size a user is allowed to specify with the SO_SNDBUF or SO_RCVBUF options. Attempts to use larger buffers fail with EINVAL. The default is 256K. It is unwise to make this parameter much larger than the maximum buffer size your applications require, since that could allow malfunctioning or malicious applications to consume unreasonable amounts of kernel memory. tcp_mss_def Determines the Default Maximum Segment Size for TCP nonlocal packets (ie, packets to be sent to different networks or subnets). The default value is 536 bytes. tcp_mss_max Determines the Maximum Segment Size for TCP nonlocal packets Maximum negotiated MSS. Default 65495 tcp_old_urp_interpretation **removed TCP Urgent Data Pointer 0 = Old BSD style RFC 793 (Pointer points at urgent data +1). 1 = Modern Style RFC 1122 (Pointer points at urgent data). The default value is 1 ** older Solaris 2 see S69inet: ndd -set /dev/tcp tcp_old_urp_interpretation 1 tcp_recv_hiwat This parameter specifies the default value for a connection's receive buffer space; that is, the amount of buffer space allocated for received data (and thus the maximum possible advertised receive window). In most cases, tcp_recv_hiwat should be identical to tcp_xmit_hiwat. The default value is 8192 (8k). tcp_rexmit_interval_initial initial retransmit timeout interval. ( first retransmit ) Default value is 3000 ( 3*SECONDS ) changed from 500*MS tcp_rexmit_interval_max maximum retransmission interval. This is the maximum wait interval between two consequitive retransmissions The Default value is 240000 (240*SECONDS ) Changed from 6000 (1*MINUTES) tcp_rexmit_interval_min minimum retransmission interval This is the minimum wait interval after the initial retransmit before retransmitting The Default Value is 200 ms tcp_slow_start_initial workaround to use on solaris where the clients are not compliant with the current TCP slow-start standard (RFC2001). Included in 2.5.1 103582-15 and above Default Value is 1 . ( to implement workaround change to 2 ) Note: TCP Slow-start Initial Value Can Be Changed see bugid: 4054780 4057676 Non-Solaris clients may experience somewhat slower network performance on short-lived connections, such as http connections, when served by Solaris servers. This problem occurs because of Solaris' strict adherence to the TCP Slow-start specification (RFC2001). You can now modify the initial value that TCP Slow-start uses by tuning an ndd variable. For detailed information on how to modify this variable and an explanation of this behavior, go to the section titled "Sun Performance Information" under "Sun On the Net" at http://www.sun.com. tcp_smallest_anon_port Determines the smallest TCP port number that may be used for an anonymous connection. Solaris allocates ephemerical ports above 32768 The default value is 32768. tcp_xmit_hiwat This parameter specifies the default value for a connection's send buffer space; that is, the amount of buffer space allocated for sent but unacknowledged data. In most cases, tcp_xmit_hiwat should be identical to tcp_recv_hiwat. The default value is 8192 (8k). tcp_xmit_lowat Determines the minimum value of the TCP transmit buffers. The default value is 2048 (2k). Solaris 2.6 TCP large windows ndd configuration parameters: TCP large windows provides the support described in RFC1323. This support is designed to improve performance over large bandwidth or delay networks such as ATM or satellite networks by using windows that exceed the normal 65535 limit. 2.6 TCP large windows tcp_wscale_always If this parameter is nonzero, a window scale option is always sent when connecting to a remote system. Otherwise, the option will be sent if-and-only-if the user has requested a receive window larger than 64K. The default is zero. Regardless of the value of this parameter, a window scale option is always included in a connect acknowledgment if the connecting system has used the option. tcp_tstamp_always If this parameter is nonzero, a timestamp option is always sent when connecting to a remote system. The default is zero. Regardless of the value of this parameter, a timestamp option is always included in a connect acknowledgment (and all succeeding packets) if the connecting system has used the option. tcp_tstamp_if_wscale If this parameter is nonzero, the timestamp option is sent when connecting to a remote system if the user has requested a receive window larger than 64K (that is, if a window scale option with a nonzero scale is being used). The default is zero. tcp_host_param This parameter is a table of IP addresses, networks, and subnetworks, along with default values for certain TCP parameters to be used on connections with the specified hosts. ( Read Only )

3.2.3: UDP Variables

 udp_def_ttl Determines the default Time To Live for UDP packets. The default value is 255. udp_do_checksum Determines whether checksums should be done for UDP packets. The default value is 1 (True). udp_recv_hiwat Determines the maximum value of the UDP receive buffer. This is the amount of buffer space allocated for UDP received data. The default value is 8192 (8k). udp_smallest_anon_port Determines the smallest UDP port number that may be used for an anonymous connection. The default value is 32768. udp_xmit_hiwat Determines the maximum value of the UDP transmit buffer. This is the amount of buffer space allocated for UDP transmit data The default value is 8192 (8k). udp_xmit_lowat Determines the minimum value of the UDP transmit buffer. The default value is 1024 (1k).

3.2.4: ARP Variables

 arp_cleanup_interval This is the time that ARP will hold on to unsolicited information in case IP needs it. The default is 300000 ms (5 minutes).

4.0 Some Frequently Asked Questions 

4.1: Miscellaneous Questions

 QUESTION: What RFCs does Sun TCP/IP follow? 

ANSWER: Sun follows RFC 793 for TCP, RFC 768 for UDP, RFC 791 for IP, and RFC 1122 overall. RFC 1323 is implemented in 2.6 and above. See section 6.1 for more information. 

QUESTION: Will TCP/IP kill idle connections? 

ANSWER: No. If a connection goes idle for an extended amount of time, probes will be sent out to verify that the remote machine or connection has not gone down. However, provided that everything is still running, TCP/IP connections should stay live forever. 

4.2: Questions on Ports 

 QUESTION: Why do ports get stuck in the TIME_WAIT state? 

ANSWER: This is due to the 2MSL timeout value, which is a part of the TCP specification. After a connection has been closed by both the client and the server, the port becomes unavailable for a certain amount of time, so that a new program does not inadvertantly get packets that were intended for the old program. On Solaris machines, the 2MSL value may be modified by adjust the /dev/tcp tcp_close_wait_interval ndd variable. See Section 3.2.2. 

QUESTION: Why do I get "address already in use" when I try and reuse a port which a previous program had used. 

ANSWER 1: It could be that the port is still in the TIME_WAIT state (see above). You may confirm this by running netstat, and examining the port in question. If this is the case, you must simply wait the couple of minutes it will take for the port to get out of the TIME_WAIT state. 

ANSWER 2: It could be that the program you are using does not correctly list the port as one that may be reused. You should verify that your program is setting the SO_REUSEADDR socket option. 

4.3: netstat Questions

 QUESTION: Why does netstat hang when I run it? 

ANSWER: This is usually due to an error in name resolution. Run netstat with the -n option to verify that this is the case: % netstat -n % netstat -rn If you find that netstat does not hang when you run with the -n option, you should investigate your naming services (DNS, NIS, NIS+) for further problems. 

4.4: Web Server TCP/IP Optimization

QUESTION: How do I increase the listen backlog described in my HTTPD documentation? 

ANSWER: This may be modified only on Solaris machines. On these machines, you will want to adjust the /dev/tcp tcp_conn_req_max variable. Section 3.2 explains how to set ndd variables temporarily or permanently. On Solaris 2.4 or lower, you can use ndd normally to set the listen backlog up to 32, from the default of 5: ndd -set /dev/tcp tcp_conn_req_max 32 By modifying your kernel, you can increase the backlog even higher. echo "tcp_param_arr+14/W 0t128" adb -kw /dev/ksyms /dev/mem ndd -set /dev/tcp tcp_conn_req_max 128 You must make sure that you have at least patch 101945-36 installed before you try this. Values higher than 128 are not suggested. These lines should both go into /etc/rc2.d/S69inet to make the change permanent. On Solaris 2.5 , you can set the listen backlog up to 1024 normally: ndd -set /dev/tcp tcp_conn_req_max 1024 2.5.1 w/ tcp patch and 2.6 have 2 queues that replace the tcp_conn_req_max Starting in Solaris 2.5.1 w/patch 103582-11 or higher and Solaris 2.6, tcp_conn_req_max no longer exists. The ndd tcp_conn_req_max parameter has been replaced with two enhanced parameters: tcp_conn_req_max_q and tcp_conn_req_max_q0 The default values of these new parameters are equivalent (in performance terms) to the value of 1024 in tcp_conn_req_max (before tcp patch 103582-11) These two variable were created by Solaris 2.5.1 patch: 103582 (Version 11 on up) and built-in to Solaris 2.6. This Solaris patch addressed the TCP SYN attack threat which was a CERT advisory and bug 1182957. To increase maximum connections w/patch 103582-11 or higher, use this: /usr/sbin/ndd /dev/tcp -set tcp_conn_req_max_q 1024 

QUESTION: What else can I do to increase Web Server Performance? 

ANSWER: You should adjust the listen backlog up, as is suggested in your Web Server documentation. You will probably also want to increase the size of the send, receive and congestion windows: ndd -set /dev/tcp tcp_cwnd_max 65535 ndd -set /dev/tcp tcp_xmit_hiwat 65536 ndd -set /dev/tcp tcp_recv_hiwat 65536 Note that under Solaris 2.5 and higher, tcp_cwnd_max is already set to 65535 by default. Also note that these ndd settings only apply to Solaris. A2: Upgrade to Solaris 2.6, faster CPU's, more memory, Fastethernet ... 

5.0: Patches 

The following is the list of all of the TCP/IP related patches for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having TCP/IP problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com. 

5.1: SunOS TCP/IP Patches

Patch-ID# 100584 SunOS 4.1.1,4.1.2,4.1.3: TCP socket and reset problems 

101790-01 SunOS 4.1.3_U1: TCP socket and reset problems Fix some problems regarding TCP resets, and the usage of the getsockopt function. 

100584-08 SunOS 4.1.3: TCP Interface Jumbo Patch 

102010-02 SunOS 4.1.3_U1: TCP interface Jumbo Patch. Fix a wide variety of problems having to do with TCP connections. 

5.2: Solaris TCP/IP Patches   

101318-81   SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) Solaris 2.4 

101945-42   SunOS 5.4: jumbo patch for kernel Solaris 2.5 

103447-10   SunOS 5.5: tcp patch 

103093-22   SunOS 5.5: kernel update 

103399-02   SunOS 5.5: /kernel/strmod/sockmod patch Solaris 2.5.1 

103582-16   SunOS 5.5.1: /kernel/drv/tcp and /usr/bin/netstat patch 

103597-04   SunOS 5.5.1: /kernel/strmod/sockmod patch 

103640-20   SunOS 5.5.1: kernel patch 

105097-01   SunOS 5.5.1: usr/lib/libsocket.a and usr/lib/libsocket.so.1 patch Solaris 2.6 

105529-03   SunOS 5.6: /kernel/drv/tcp patch 

105214-01   SunOS 5.6: /kernel/fs/sockfs patch 

NOTE:  These patches fix a large number of TCP/IP and other network problems. They should be installed on every networked machines. 

6.0: Known Bugs and RFEs The following bugs & rfes represent known open issues regarding TCP/IP 

6.1: RFEs  

1179428 Request for implementation of RFC 1323 for tcpip performance This RFE requests that RFC 1323 be implemented under Solaris, so that performance on satellite or delayed links can be improved. 

 7.0 References 

7.1: Important Man Pages

arp etherfind ip ndd (Solaris Only) netstat snoop tcp udp 

7.2: Sunsolve Documents

The following SunSolve documents may contain some additional information, which is not covered in this Tip Sheet. 

7.2.1: FAQs 

1048 IP interface questions and answers 1202 TCP/IP applications have slow response over asynchronous commu 

7.2.2: Infodocs 

 2194 Internet Protocol Overview (IP and ICMP) 2195 Transmission Control Protocol (TCP) 

7.2.3: SRDBs 

 5819 how to set socket keep alive timeout length 6729 UDP checksums for NFS 11416 what are the ARP values set by ndd? 

7.3: Sun Educational Services  

 Sun Educational Class which covers TCP/IP tuning is TCP/IP Network Administration SA-389. 

7.4: Solaris Documentation  

There is no Solaris Documentation which covers TCP/IP tuning to this level. 

7.5: Third Party Documentation  

TCP/IP Illustrated, Volume 1_, by W Richard Stevens, published by Addison-Wesley, ISBN 0-201-63346-9 This is a superb book covering TCP/IP. It explains the majority of the terms which are outlined in the above document, and gives a really good overview of networking as a whole. 

7.6: RFCs

 There are a huge number of RFCs which cover TCP/IP and other networking protocols. RFCs are the internet-written documents that define the specifications of many common networking programs. RFCs can be retrieved from nic.ddn.mil, in the /rfc directory. 

8.0: Supportability 

 SunService is not responsible for the initial configuration of your TCP/IP environment. In addition, SunService can not diagnose your TCP/IP performance problems, nor suggest TCP/IP tuning guidelines. We can help resolve problems where TCP/IP is not behaving correctly, but in such cases the contact must be a system administrator who has a good understanding of TCP/IP. 

9.0: Additional Support

 For initial configuration, or TCP/IP performance tuning guidelines, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local Sun Integration or Sales office.