OpenVms/Telnet problem with many concurrent interactive connections requests

[Wim Van den Wyngaert]

tcptrace should be available according to documentation of 5.1. If not something is strange/wrong on your site.

Wim

[Wim Van den Wyngaert]

According to doc you must execute SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM first to get the command. That's not the case in 5.3 but you can try.

There were also some DNS failover problems in some 5.1 versions. May be timeout was also handled differently (thus explaining the 1 min).

Wim

[Volker Halle]

Maurizio,

consider to read the following article and see, if it applies to your situation:

http://h18000.www1.hp.com/support/asktima/communications/CTI_SRC021219001467.html

Check for symptoms with

$ ANAL/SYS
SDA> tcpip sysconfig socket
...
SDA> EXIT

What are the values for sobacklog_drops and
sobacklog_hiwat ?

Volker.

[Maurizio Rondina]

Wim, the TCPIP$DEFINE_COMMANDS.COM is already on my login.com, however i solve the problem of tcptrace, and now you can see the log on attachment: I trace the connection of the client 192.168.104.178 to the ES40 server 192.168.1.3, while it try to open a telnet connection. In that moment, with no problems, only few seconds wait.

Robert, i think that it's necessary my on-site visit to verify all points of view.

[Rob Leadbeater]

Hi,

I've only a little experience of VMS, but this statement stands out:

> 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.

I would ask your customer on what grounds they can make that decision, especially as it sounds like the server was still looking at the old resolver...

It would also be interesting to find out whether these problems started happening when the DNS server was changed.

Cheers,

Rob

[Maurizio Rondina]

Volker,

the HP Article is very intresting (also if it concern with tcpip 5.3eco1, and not not tcpip5.1), i follow his suggestion, when the problem happen.

The strange is that, the days this happen, no problems there are for the logins of the first users, than at 8.15am in 5 minutes over 100 simultaneous login are requests. They, all wait for the Username prompt, but someone have reply in 2 minutes, others in 5 minutes, other even after 30 minutes. Then, all new connection requests, are normally satisfacted in one second. Seem there is a congest queue of connection requests.

For the sobacklog_drops and
sobacklog_hiwat values this is the actual (without problems) situation:

sobacklog_drops 2058
soback_hiwat 8

Thanks.

[Maurizio Rondina]

Rob,

Few years ago the customer make the decison to carry the DNS to Windows2003 server, and leave the one on the OpenVms system, because they believe that on this platform, the management was more simply, also for their internal techicians, and not need a OpenVms specialist (in this region of Italy, i'm the only, and there are only few systems).

They realize the project, without consider the new OpenVms Dns role, and leave it as was.

the 192.168.1.9 server, instead, was an older proxy server to which the OpenVms system (that only store the local names for local zone) ask for the forwarding requests, for public names resolving.

Also the 192.168.1.9 proxy server was substituted by one other (now 192.168.4.9) without consider the OpenVms system.

The problems, however, don't started happening with this changes.. sure not for the change of the proxy server, may be for a recently Dns configuration operation on the actual Dns on Windows 2003 server, that i don't know.

[Volker Halle]

Maurizio,

if the 'problem' exists for the TELNET connections and it is the backlog queue problem, other IP protocols (e.g. FTP) should be fine. But even a $ TELNET localhost will hang. You can use these tests to easily rule out other speculations...

From your data provided, it shows that you've hit this problem in the running system. Consider to watch the sobacklog_drops counter, if it increases during the time the problem is evident, it will confirm my analysis.

This is a very unusual scenario, but I've seen it before and HP service never found the problem, so I had to be called in.

Volker.

[Wim Van den Wyngaert · Accepted solution]

Your trace starts at 17:42:41.79 and has nothing abnormal. If you should trace again, also trace the first name specified in the name server list.

To add to Volkers solution : note that after a SYN drop the retransmit is done by the client after 5 seconds (surely some config item but could be hardcoded). And a timeout is 75 seconds.

Wim

[Maurizio Rondina]

Vim and Volker,

now I think I must wait the morning when the problem happen againg, and in that moment apply your suggestions, for more analysis.

Thanks.