Network trouble DNS

[Oscar Paredes Alvarez]

We have two problesms, the server app and te server database are connected with the server DNS but have problems, the comunications is very slow and send the message:

dbsnet:/ >netstat -na |grep WAIT
tcp 0 0 18.35.10.124.1521 18.36.70.50.4504 FIN_WAIT_2
tcp 0 0 18.35.10.124.21 18.38.10.90.4395 FIN_WAIT_2

Any sugestion ?

[Geoff Wild]

Change to hosts first in nsswitch.conf on both the db and app server?

and/or add to resolve.conf:

retrans 2500
retry 2


Rgds...Geoff

[rick jones]

FIN_WAIT_2 has _nothing_ to do with DNS. FIN_WAIT_2 is the state a TCP endpoint enters when it has sent a FINished segment to the remote and the remote has ACKnowledged that FINish segment. It is now waiting for a FINished segment from the remote.

At this point, one of a few things has happened:

1) The remote application/stack is broken and is using an "abortive" close of TCP - this sends a ReSeT segment which is _not_ retransmitted and can be lost

or

2) The remote application is buggy and has ignored the notification of the receipt of the FIN

or

3) It is supposed to be that way as the application wants a simplex connection where data only flows from the remote to the side in FIN_WAIT_2 - that is to say that FIN_WAIT_2 is a perfectly valid "receive only" state for a TCP endpoint.

Further, it would take a LOT of FIN_WIAT_2 endpoints to make the TCP stack sweat. Thousands and thousands of them.

When communication is slow, start checking statistics - start with netstat -p tcp on the app and db system. Look for retransmissions, retransmission timeouts and the like. it is best to take two snapshots separated by a little time and run them through beforeafter to subtract one from the other (ftp://ftp.cup.hp.com/dist/networking/tools/)

if that shows a non-trivial retransmission rate, then check the link-level statistics with lanadmin.