Tips for TCP/IP monitoring and tuning to make your network sing

May 08, 2001, 1:08 PM —

Q: Which of the TCP protocol counters are worth watching? How can I
tell if there is a problem, and what should I tune?

--Fin_wait Freda

A: TCP/IP is simple in concept, but the reality of making it work reliably
in a wide range of conditions adds a lot more complexity. There are a
large number of protocol counters that can be viewed with netstat
-s, but only a small number of them are of general interest.
There is another set of values that can be obtained and set using the
ndd command.

The netstat -s command lists several protocols, but I just
show the TCP data that is reported by Solaris 2.5.1.

TCP     tcpRtoAlgorithm     =     4     tcpRtoMin           =   200
        tcpRtoMax           = 60000     tcpMaxConn          =    -1
        tcpActiveOpens      =  3283     tcpPassiveOpens     =   234
        tcpAttemptFails     =     0     tcpEstabResets      =   100
        tcpCurrEstab        =     6     tcpOutSegs          = 80370
        tcpOutDataSegs      = 57395     tcpOutDataBytes     =9854298
        tcpRetransSegs      =  4826     tcpRetransBytes     =644526
        tcpOutAck           = 23486     tcpOutAckDelayed    =  5081
        tcpOutUrg           =    34     tcpOutWinUpdate     =     3
        tcpOutWinProbe      =     5     tcpOutControl       =  7066
        tcpOutRsts          =   132     tcpOutFastRetrans   =   196
        tcpInSegs           = 96006
        tcpInAckSegs        = 52302     tcpInAckBytes       =9856462
        tcpInDupAck         =  9887     tcpInAckUnsent      =     0
        tcpInInorderSegs    = 63348     tcpInInorderBytes   =20318851
        tcpInUnorderSegs    =     0     tcpInUnorderBytes   =     0
        tcpInDupSegs        =     0     tcpInDupBytes       =     0
        tcpInPartDupSegs    =     0     tcpInPartDupBytes   =     0
        tcpInPastWinSegs    =     0     tcpInPastWinBytes   =     0
        tcpInWinProbe       =     6     tcpInWinUpdate      =     4
        tcpInClosed         =    15     tcpRttNoUpdate      =  1286
        tcpRttUpdate        = 20744     tcpTimRetrans       =  1514
        tcpTimRetransDrop   =     0     tcpTimKeepalive     =   168
        tcpTimKeepaliveProbe=     0     tcpTimKeepaliveDrop =     0
        tcpListenDrop       =     0

To make sense of this, and to pick out the data of interest, I'll
start with a simplified description of TCP, and relate this to the data
reported by netstat -s.

TCP is a reliable, connection-oriented protocol. You have to
establish a connection between two machines, send data, make
sure it gets there safely, then shut down the connection. At any point
in time there will be some number of connections in each of these
states. It's rather like making a telephone call -- dialing, talking,
then hanging up. (The common alternative to TCP is UDP, which is much
more like the postal service; you send a packet and hope that it gets
there.)

Connections

Some connections are opened by your system as it calls out to another
machine. Conversely other connections are opened as a result of another
machine calling in. Again this is just like a phone call, where you
could be making the call or receiving the call. Once the call is
established it is symmetric; both sides can send and receive data as
they wish, and either side can terminate the connection.

The outgoing calls you make are called "Active Opens." You decide
who to call and why. An outgoing rlogin, or Web browser
request causes an active open. The incoming calls are called "Passive
Opens" as they occur without any activity on your part. You just have
to have a program running that is waiting to "pick up the phone." For
example a Web server listens on port 80 for any incoming requests.
There are two counters that keep track of how many of each type have
occurred.

        tcpActiveOpens      =  3283     tcpPassiveOpens     =   234

You should keep track of the rate at which opens occur. The
fundamental performance limit of most Web servers is the rate at which
they can perform the passive open. Most systems can run at several
hundred connections per second. If you need more, you must split the
load over multiple systems.