TCP disconnect problem

[Jack Fan]

Can someone help me to identify this problem.
Our network team have deploy QoS device between sites. Before that, everythings okay in ERP system. But after deployment, some user kick off long database transaction or report on server, that will be killed TCP connection, once transaction exceed 20 min.
But, once QoS device removed those problem away. And important, only this kind of telnet service have impact.

Can any parameter to be changed or modify to fit QoS service?

Regards,
Jack Fan

[Steven Sim Kok Leong · Accepted solution]

Hi,

This can happen if the QoS devices implement some form of session idle timeout. If it is a HP-UX server, check the tcp keepalive interval.

# ndd -get /dev/tcp tcp_keepalive_interval

If this interval is 20 mins, when a client sends a job over to the server which processes for more than 20 mins (i.e. during these 20 mins, the server is processing and there is no network traffic at all) before sending the results over the network back to the client, the connection will be disconnected.

To fix this problem, set the tcp_keepalive_interval to a longer duration. The default of 2 hours is normally long enough.

Hope this helps. Regards.

Steven Sim Kok Leong

[Stefan Farrelly]

20 minutes sounds like an environment variable in the shell, TIMEOUT. Check you dont have this set, if so make it bigger or unset it.
A normal TCP timeout will be 15 mins, not 20, so I dont think you should be adjusting tcp timeout values using ndd. Have you tried nohup on the remote server so if you do disconnect the job will continue to run ?

[Steven Sim Kok Leong]

Hi Jack,

Extracted below for your convenience with regards to tcp_keepalive_interval. It is a common issue especially with programs that send data across the network too infrequently (e.g. FTP control channel waits for FTP data channel to complete transfers and times out while waiting for too long).

# ndd -h tcp_keepalive_interval

tcp_keepalive_interval:

Interval for sending keep-alive probes.

If any activity has occurred on the connection or if there is
any unacknowledged data when the time-out period expires, the
timer is simply restarted. If the remote system has crashed
and rebooted, it will presumably know nothing about this
connection, and it will issue an RST in response to the ACK.
Receipt of the RST will terminate the connection.

If the keepalive packet is not ACK'd by the remote TCP, the normal
retransmission time-out will eventually exceed threshold R2,
and the connection will be terminated.

With this keepalive behavior, a connection can time-out and
terminate without actually receiving an RST from the remote TCP.
[10000, 10*24*3600000] Default: 2 * 3600000 (2 hours)

Hope this helps. Regards.

Steven Sim Kok Leong