UCX intermittent telnet connection problems

[John A. Beard]

Nothing in life is ever simple...

Jim,

I'm going to have to extend this into tomorrow, but here's a bit of history to what happened at one of the sites reporting a problem connecting into the server (which by the way is in Austria - I'm in Canada). I could not even ping the box, so I had to rely on a non VMS tech at the plant to log in and reboot. There had been no Telnet sessions for approximately 8 hours, so the folks there were anxious to get things up again a.s.a.p. The local tech person did confirm that there the led on the NIC card was showing green and that the switch was not showing problems with other connections going through it. I ran anal/err on the box after it came back and I couldn't see any error messages relating to a 24 hour window for the time of the problem. Accounting showed that batch jobs continued to run unaffected during this period also.


I was not aware of any of the commands included in my attached document at the time, as these were taken from other threads linked to similar problems after I started googling for similar problems. I should just mention that the attached output was from another server in France that denied Telnet sessions for periods of up to 10-15 minutes (I believe this happened more than once).

[Jim_McKinney]

> at the plant to log in and reboot

Here're some things to think about - and this is not to suggest that the issue isn't solely telnet related - just trying to clearly define the issue.

Are the users local or remote to the system? Do they all follow the same network path for entry? Are any other network protocols used and were they affected? Were users that were already connected unaffected?

[John A. Beard]

Jim,

The majority of the users would have been local, although myself and some other European support people would have been trying to connect remotely.

I don't know about the path that everyone would have been using


UCX is the principal protocol, with the majority of tasks being either Telnet or FTP. Decnet is used for internal mail box communication only.

From what I was told, the Tech at the plant maintained that no other interactive sessions showed up when he issued the command $sh us/int command from the console.

[Jim_McKinney]

I suggest that if/when this occurs again that you attempt to connect via FTP. You noted that there were no OPCOM messages related to network issues. I presume that you also didn't observe any messages noting that there were no more PCBs available indicating that you'd run out of process slots (you also noted that someone was able to access the system from the console so if this wasn't already logged in it would have required a free PCB)? If possible, should this occur again, and there is some telnet ready system on the LAN that hosts this Alpha server, have the local folks attempt to telnet in. You might also have the local folks access the system on the console and attempt to initiate an outbound session. Also, rudimentary things like SHOW MEMORY/FULL and a SHOW SYSTEM might be informative while the event is occurring. Right now, you might take a look at the NICs counters in LANCP ($ MCR LANCP SHOW DEVICE/COUNT) - I don't know how to access the internal TCP counters using UCX (MultiNet is my stack of choice). During suspected network driven denial-of-service incidents TCP ARP and connection tables often prove interesting (and again I don't know how to tell you to view them using UCX).

[Volker Halle]

John,


I was not aware of any of the commands included in my attached document at the time


If the data in your first attachment was from another server or even from a server, on which the TELNET connection problem has happened, but collected after the reboot, this information is mostly useless.

You need to obtain this kind of information at the time the problem exists or at least afterwards before a reboot.

If the problem exists and you can't access the server remotely (consider to log on another OpenVMS server in the LAN and use SET HOST or SET HOST/LAT), consider to force a crash while the problem exists instead of just rebooting the node. The dump might then allow for the problem to be analyzed lateron.

Volker.