HP-UX TCP/IP Performance White Paper, March 2008

47
It is also possible that those settings are good, but one or more applications have stopped calling
accept() against their listen socket(s) - perhaps they are saturated, or perhaps they are caught in an
infinite loop.
1585 connect requests dropped due to no listener
This is the number of connection requests (SYN segments) dropped because there was no local endpoint in
the LISTEN state. This could be the result of someone forgetting to start a server application, or configuring
the wrong well-known port number at either the server or client. It could also be the result of a "probe" from
some remote system looking for a particular service that is not running on the system.
0 suspect connect requests dropped due to aging
This is the number of suspect connection requests dropped because it exceeds the maximum number of
suspect connections that will be allowed to persist in SYN_RCVD state. See the ndd tunable
tcp_syn_rcvd_max which controls the SYN attack defense of TCP. For SYN attack defense to work,
tcp_syn_rcvd_max must be large enough so that a legitimate connection will not age out of the list
before an ACK is received from the remote host.
0 suspect connect requests dropped due to rate
This indicates that there are excessive suspect connections piled up and the remote system has not had valid
connections established previously.
UDP:
0 incomplete headers
On an 11i system, the field should have no meaning.
0 bad checksums
A non-zero value for this statistic means that either the network is corrupting data occasionally, or there is a
high rate of IP datagrams fragments being received and the 16-bit IP datagram ID between this and one or
other hosts is wrapping quickly enough to generate "Frankengrams." "Frankengrams" are when the
fragments of two otherwise unrelated IP datagrams which happened to have the same IP Datagram ID are
joined into one datagram - some fragments from one datagram, some fragments from the other. For more
on this, see the IP fragmentation tunable discussion in Appendix B.
0 socket overflows
A non-zero value here means that receiving UDP applications are not draining their socket buffers fast
enough. It implies that either the receiving apps need to be tuned, or they need to have some form of flow-
control implemented. It would be best for UDP applications needing larger socket buffer sizes to get them
via the programmatic interface setsockopt() socket call.
Regardless, it should be noted that simply increasing the size of the socket buffer is only going to work if the
length of the overload condition is short and the burst of traffic is less than the size of the socket buffer.
Increasing the socket buffer size will not help if the overload is sustained.