OpenVms/Telnet problem with many concurrent interactive connections requests

[Maurizio Rondina]

An old ES40 Alphaserver, with OpenVms 7.3 and tcpip 5.1, for many years don't have any problems with telnet connections, now, on the morning (ony few days, expecially on Monday) when over 100 users try to login on to the system, this don't prompt for the "Username", wait without any response for few minutes, and finally reject the connection. Ony few users at time can connect, and to login all the users half hour need.

After 30-40 minutes, the problem is solved. The normal time connection (less one second) is established, for any user want to open a new session.

I just verify the Telnet LIMIT parameter and other parameters: arUe all correct.
Unfortunately, for other problems, the customer cannot upgrade the OpenVms and TCPIP versions.

On the same network there are others OpenVms system, that normally reply to the telnet connections requests of the same clients, on the same time when ES40 don't reply.

All users use the Ericom PowerTerm525 Telnet Emulator, installed on all WindowsXp clients.
Note that also from the Windows command prompt, the problem is the same. To exclude name resolution problems (DNS name, Netbios name), i try directly with ip address, but the problem is the same.

[Wim Van den Wyngaert]

$ ucx show nam
Is the "timeout" low, e.g. less 4 sec ?
What is the value of retry ?
Are all dns servers specified present (ping) ? Try swapping the specified servers (e.g. S1,S2 becomes S2,S1).

Note that for IP adresses you have reverse address lookup.

Can you do a tcptrace /prot=ip/fu/pack=10000 between VMS and a PC and post that ?

Wim

[Steven Schweda]

> To exclude name resolution problems (DNS
> name, Netbios name), i try directly with
> ip address, [...]

If the Telnet server tries to do a reverse
(number-to-name) look-up on the client, then
it won't matter whether you specify the
server by name or by address.

> [...] and finally reject the connection.

Actual error message?

[Maurizio Rondina]

Wim, results of TCPIP show man parameters is:

Retry: 4
Timeout: 4
Servers: A1, 192.168.1.9

Retry and timeout, are the defaults.

Server A1 repond to ping, is the same openVms system

Server 192.168.1.9 do not respond to ping, so I remove it from the BIND Resolver, shutdown and restart the BIND tcpip service, but it remain on the output of TCPIP SHOW NAM command.... So I try with the TCPIP$BINDsetup.com procedure, and now the TCPIP SHOW NAM command give:
Server: LOCALHOST

The customer say me that the 192.168.1.9 server was replaced with 192.168.1.11 dns server, a newer Windows 2003 Active Directory DNS Server.

They says that now the BIND/DNS server is not more necessary on the ES40.

for the tcptrace command results, i cannot sent to you: the verb/symbol is not recognize on TCPIP services v.5.1, may be a command released on newer versions.

Thanks.

[Maurizio Rondina]

Steven, none error message are given...

the terminal emulator's "connect box" of Power Term is browsed again after few minutes, without messages.

In this moment the telnet server normally respond and i cannot say you what happen and the error message, but i think the response is "impossible to open connection to the host".

I try when the customer call me, in the moment there is the problem.

[Wim Van den Wyngaert]

Ok, if DNS was not reesponding you should get your connection within about 10 seconds (as far as I remember of my DNS play time).

Start tcpip and do help. Is tcptrace in there ?

Wim

[Robert Gezelter]

Maurizio,

I would recommend that the problem be approached by looking carefully at real data, not by changing parameters that have been quite acceptable in the past. While it is quite possible that changes may be needed, it is far safer to make those changes based upon facts.

I would obtain an appropriate Ethernet HUB (not a switch). If managed switches are in use, then there are likely settings allowing traffic to be replicated.

I would then put a network analyzer (e.g., WireShark; which is freeware and available for download) on the line between the OpenVMS system and the network infrastructure. When the problem occurs, it will then be possible to see precisely what is (and what is not) happening. Save the resulting trace file to disk for analysis.

Many things could be causing this problem. Not all of them involve the OpenVMS system.

Also if there is a shortage of internal expertise on looking at network traces, consider whether outside resources should be retained (disclosure: My firm provides such services, as do the firms affiliated with several other active contributors to ITRC).

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

[labadie_1]

Hello

Do you get some data displayed at sys$output if you do
DEFINE TCPIP$SOCKET_TRACE 1
telnet nodename
or telnet @ip

If you prefer to get the display in a file
DEFINE TCPIP$SOCKET_TRACE - SYS$LOGIN:TCPIP$SOCKET_TRACE.LOG

and after your telnet, look at the file

[Maurizio Rondina]

to Wim, the tcpiptrace isn't available on tcpip 5.1, i just verify this on tcpip help.

when the problem happen, the waiting time is over than 10 seconds, may be over 1 minute, so i think the problem is due to a more complex network problem, as say Robert.

Thank to Robert for the reccomendation, that i already generally use. Inside my customer are not internal expertise, that can analize network traces.

Unfortunately, i don't know the complete network infrastructure, the customer ask me to solve this problem as "ES40" problem, because is the only server that have the problem.

Now i'm working remotely on the problem, if necessary i must go on-site few days at 8,15am o'clock, when in few minutes, about 150-200 login are request and hope that the problem occurs in that moment.

For labadie, i try with your suggestion: none log file are created. I think, as i say above to Wim, that tcpip 5.1 doesn't support the trace feature.

About the both suggestion of Wim and labadie, i think that the trace is needed on the client side, not on the ES40 side.

Thanks to all.

[Robert Gezelter]

Maurizio,

With all due respect, my suspicion is that a network trace (with a monitor, not TCPTRACE) at the server will illuminate what is happening.

Tracing at the client side will only show a single client's perspective. The aggregated trace near the server will show the conversations that are working, as well as those that are not.

I would also suggest ensuring that OpenVMS accounting is enabled, at least for the period of the surge.

And yes, I have seen many problems reported as "server" problems that were actually problems with underlying infrastructure that were experienced as "server" problems.

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