OpenVms/Telnet problem with many concurrent interactive connections requests

[Maurizio Rondina]

Today customer tell me that since 6-may-2008 when I delete the 192.168.1.9 server from DNS configuration and from bind resolver, and rebuild the TCPIP$BIND.CONF with the wizard TCPIP$BINDSETUP, all connections are very fast.
So today afternoon, to make a test, i try to stop and disable the BIND service from TCPIP$CONFIG.COM, to look if the problem is in effect a DNS problem as seems.
Only few hours (in the afternoon there are few users that try logins) and customer call me to say that all connection now are newly very slow.
I connect to the system, and launch the tcptrace (see the file in attachment) before try the telnet connection. Also for me the connection wait over 20 seconds.
Note that in the tcpip trace, there are no packets after the first ACK of the client, for 21 seconds.

...(follow)

[Maurizio Rondina]

.....then I enable and start the BIND server on TCPIP$CONFIG, and in few minutes the connections are newly very fast: see in the tcptrace in attachment, that only in 1 second there is the reply of the server to the client ACK/SYN.

I think the problem is solved, i wait only Monday (usually critical morning), when over one hundred logins requests will ask to the system in few minutes.

I will inform you...

Thanks

[Maurizio Rondina]

This morning 176 telnet connection was opened in 15 minutes without problems, and without delay time.

Now I'm sure that the problem was a "DNS telnet reverse lookup problem" due to modifications of the network configuration of external Microsoft consultants (new dns transfer server "any" move from 192.168.1.9 to 192.168.4.9. new Windows 2003 DNS server inserted with ip 192.168.1.11, new local zone "customer.local." created with pointer CNAME in the original "customer." zone the only that the OpenVms system know) without consider OpenVms System configurations.
Now I tune the TCPIP$BIND.CONF dns configuration file, modifying all relevant errors, and all name resolution go well: local names, zone "customer."'s names, zone "customer.local."'s names and external internet names.
The connection time now is very low.

The only doubt remains, is why the problem occurs only few times (occasional problem), and not any time (persistent problem).

If you can suggest something...

i leave open the thread for this.

Thanks to all.

[Robert Gezelter]

Maurizio,

A packet-by-packet trace will show precisely what is happening (or course, one does need the time and budget to go through the messages one at a time).

Two possibilities come to mind:

- are the problem surges preceeded by periods of idleness? If so, perhaps the DNS cache is covering the problem.

- is there a network problem that is causing the DNS resolution requests to be dropped somewhere in the network?

- Bob Gezelter, http://www.rlgsc.com

[Neelmani Pandey]

Yup I too believe that DNS cache was covering the issue,
As the client which is being connected may be resolving using the cache.

[Wim Van den Wyngaert]

Still don't understand the 20 sec delay. If the first DNS server was not responding, it should contact the 2nd after 4 secs.

But may be your version works as follows :
1 original transmit and 4 retries. So 5 times 4 sec = 20 sec. Check ucx help set nam/time. May be there is some info.

Wim