And - in OpenSolaris, it's bumped here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/stand/lib/tcp/tcp.c#1006
:) And - here - http://docs.sun.com/app/docs/doc/817-6223/chp-mib?a=view you can read about it in a little more detail from a dtrace perspective and what it means in a solaris context (pretty much the same(ish)). And - keeping in the dtrace vein - if you have root access, which I suspect you will, you could do something like: dtrace -n 'mib:ip::tcpAttemptFails { @agg[pid,execname,ustack()]=count(); }' (All one line) and see which processes are having issues, and what their stack looked like. Then - if you were feeling really brave, you could perhaps consider playing with truss, dtrace or other friends, to work out what port # they are trying to do whatever they are trying to do it on. Or - As you *should* already know *exactly* which ports should be in use... (heh heh) you can just look it up! Nathan. On 6/03/09 01:34 PM, A Gupta wrote: > Looking at the Linux source tree, TcpAttemptFails is defined in > include/net/snmp.h and incremented in net/ipv4/tcp_input.c, > net/ipv4/tcp_output.c and net/ipv4/tcp_timer.c on a failed connection. > I guess try tuning your TCP stack. > > Cheers, > > A > > On Thu, Mar 5, 2009 at 8:26 PM, Chris Dimo <dimo at mail.org> wrote: >> Folks, >> can anyone explain in simple terms what "tcpattemptfails" ( netstat -s >> ) means and what perhaps would cause this to increment around 10-15 units >> per 30 seconds ? >> >> We have a situation where we moved servers into a new firewall complex and >> suprise suprise, it is terribly slow and users have been complaining. ive >> been running netstat, ping -s etc..and have the following results. >> >> qcmw002z# ping -s au1240s >> PING au1240s: 56 data bytes >> 64 bytes from au1240s (201.3.156.32): icmp_seq=1. time=2.91 ms >> 64 bytes from au1240s (201.3.156.32): icmp_seq=2. time=3.62 ms >> 64 bytes from au1240s (201.3.156.32): icmp_seq=3. time=3.74 ms >> 64 bytes from au1240s (201.3.156.32): icmp_seq=4. time=3.08 ms >> 64 bytes from au1240s (201.3.156.32): icmp_seq=5. time=3.25 ms >> ^C >> ----au1240s PING Statistics---- >> 6 packets transmitted, 5 packets received, 16% packet loss >> round-trip (ms) min/avg/max/stddev = 2.91/3.32/3.74/0.36 >> >> ----- >> >> >> Thu Mar 5 20:14:08 EST 2009 >> tcpAttemptFails =144697 tcpEstabResets = 4154 >> tcpRetransSegs =241399 tcpRetransBytes =278717070 >> tcpOutRsts =223765 tcpOutFastRetrans = 141 >> tcpRttUpdate =3633063 tcpTimRetrans =136919 >> tcpTimRetransDrop = 3339 tcpTimKeepalive = 33893 >> tcpHalfOpenDrop = 0 tcpOutSackRetrans =186148 >> >> >> Thu Mar 5 20:14:38 EST 2009 >> tcpAttemptFails =144714 tcpEstabResets = 4154 >> tcpRetransSegs =241400 tcpRetransBytes =278717070 >> tcpOutRsts =223777 tcpOutFastRetrans = 141 >> tcpRttUpdate =3633103 tcpTimRetrans =136919 >> tcpTimRetransDrop = 3339 tcpTimKeepalive = 33896 >> tcpHalfOpenDrop = 0 tcpOutSackRetrans =186148 >> >> >> Thu Mar 5 20:15:08 EST 2009 >> tcpAttemptFails =144724 tcpEstabResets = 4154 >> tcpRetransSegs =241400 tcpRetransBytes =278717070 >> tcpOutRsts =223785 tcpOutFastRetrans = 141 >> tcpRttUpdate =3633131 tcpTimRetrans =136919 >> tcpTimRetransDrop = 3339 tcpTimKeepalive = 33898 >> tcpHalfOpenDrop = 0 tcpOutSackRetrans =186148 >> >> -- ////////////////////////////////////////////////////////////////// // Nathan Kroenert nathan.kroenert at sun.com // // Senior Systems Engineer Phone: +61 3 9869 6255 // // Global Systems Engineering Fax: +61 3 9869 6288 // // Level 7, 476 St. Kilda Road // // Melbourne 3004 Victoria Australia // //////////////////////////////////////////////////////////////////
