UCX not accepting new TELNET connections

[Steve Faulkner_1]

I am running OpenVMS AXP V6.2 and UCX V4.2. Everything has been fine for months, but over the past several days, the server has stopped accepting newe TELNET connections. There have been no changes to the server configuration, and load on the server hasn't changed significantly. The output below shows that there are Waits occurring on the small buffers. I'm assuming that is the reason that new connections are not being accepted. I'm looking for help on why this would suddenly be a problem. What types of event would cause Waits to suddenly begin to occur? I'm also assuming that I could increase the number of small buffers, but without knowing probable causes, I'm afraid that the small buffers will continue to be consumed and will also exhaust the increased buffers also. Any assistance or advice is appreciated.

$ ucx sh version

DIGITAL TCP/IP Services for OpenVMS Alpha Version V4.2
on a AlphaServer 2100 4/200 running OpenVMS V6.2

$ ucx sh comm/mem
MBUF Summary
Small_static Large_static Small_dynamic Large_dynamic
Total buffers 50 10 950 0
Free 0 9 2 0
Busy
Data 0 1 0 0
Header 5 0 35 0
Socket 28 0 572 0
Prot. control 10 0 341 0
Route 3 0 0 0
Socket name 0 0 0 0
Socket options 0 0 0 0
Fragment reassembly 0 0 0 0
IP address 2 0 0 0
Size of cluster 13056 19136 53584 0

Free Current Peak Waits Drops
Small Buffers 998 1000 151 0
Large Buffers 1 15 0 0
IRPs 3 64 83 0 0

Small clusters Large clusters Non UCX buffers
Free 0 1 0

[Steven Schweda]

UCX V4.2 is older than my experience, but:

How many Telnet connections exist, and
what's the service limit? On V5.4 - ECO 5:

TCPIP SHOW DEVICE /PORT = 23

TCPIP SHOW SERVICE /FULL TELNET
(and look for "Limit:".)

Any OPCOM messages when the failure occurs?

Actual error message?

(I think that small buffers are obsolete in
V5.x, so if that's really the problem, then
you'll need to wait for useful advice.)

[Karl Rohwedder]

Steve,

have you checked things as e.g. MAXPROCESSCNT and the FTP-Server Logfiles?

regards Kalle

[Steve Faulkner_1]

Current TELNET sessions = 37
Limit = 100

No OPCOM messages when this occurs

MAXPROCESSCNT = 129 - No where near that many processes currently on the system.

[Duncan Morris]

Steve,

a) you appear to have an unpatched version of UCX. On the oldest system to which I have current access the UCX SHOW VER returns


Digital TCP/IP Services for OpenVMS Alpha Version V4.2 - ECO 3
on a AlphaServer 4100 5/533 4MB running OpenVMS V7.2-2

b) The busy values under "Socket" and "Prot. Control" look very high. This is suggestive of either a high number of current users, OR a large number of improperly disconnected sessions.

Try to report the output from

UCX SHOW SERVICE TELNET/FULL

c) Have a look at your list of TN devices to see where they have all gone with

SHOW DEVICE TN from DCL

[Guillou_2]

Hi,

In the result of ucx show service telnet/full

verify that "peak" didn't reach telnet "limit".

regards

Steph

[Volker Halle]

Steve,

$ UCX SHOW COMM will show various other resources and their maximum, current and peak values. Anything near the limit ?

Volker.

[Steve Faulkner_1]

To get my user going again in tht interim, I dynamically increased the small_buffers max to 2000. I should have inclueded the below info from the start...

$ ucx sh comm

Communication Parameters

Local host: fatboy Domain: chattanooga.gov

Cluster timer: 5
Maximum Current Peak
Interfaces 20 2 2
Device_sockets 900 623 624
Routes 65535 3 3
Services 200 39 42
Proxies 20

Type: Ethernet Free Maximum Max Bytes Minimum Min Bytes
Large buffers 20 200 377600 10 18880
Small buffers 150 2000 512000 50 12800
IRPs 20 200
Non UCX buffers 10

Remote Terminal
Large buffers: 10
UCBs: 4
Virtual term: disabled
$ ucx sh service telnet/full

Service: TELNET
State: Enabled
Port: 23 Protocol: TCP Address: 0.0.0.0
Inactivity: 1 User_name: not defined Process: not defined
Limit: 100 Active: 39 Peak: 41

File: not defined
Flags: Listen Rtty

Socket Opts: Keepalive Rcheck Scheck
Receive: 3000 Send: 3000

Log Opts: Actv Dactv Conn Error Logi Logo Mdfy Rjct
File: not defined

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0

[Karl Rohwedder]

Steve, you should really consider upgrading to the latest ECO of UCX V4.2. I think it is Eco 10, see:
ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha

regards Kalle

[Duncan Morris]

Increasing the small buffers looks like the correct response.

Examining your figures, there seems to be a very high usage (currently over 600) of device sockets:

Device_sockets 900 623 624

These will certainly have been consuming your buffers - as well as non paged memory.
Your may want to look at the non paged pool usage and make sure that your increased buffers do not consume too much space there!

Karl, I think that ECO 10 was for UCX 4.1.
The last one I saw for UCX4.2 was ECO3

try to see who/what is using all these devices. Issue UCX SHOW DEVICE, and/or SHOW DEVICE BG from DCL

[Karl Rohwedder]

re. Duncan
you were right, it is for V4.1, sorry

Kalle

[Duncan Morris]

The old CSC Sydney site shows release notes for ECO 5 (no kit link), but the last version that I can find on the itrc site is ECO 4.

ftp://ftp.itrc.hp.com/data/archived_patches/openvms_patches/axp/6.X/v6.1/ucx/4.2/

From the ECO 4 release notes:-

ECO Z 25-JUN-1999 Alpha and VAX

Images:

UCX$BGDRIVER.EXE UCX V4.2-21Z
UCX$INTERNET_SERVICES.EXE UCX V4.2-21Z (VAX)
UCX$INTERNET_SERVICES_SEC.EXE UCX V4.2-21Z (VAX)
UCX$INTERNET_SERVICES_V6.EXE UCX V4.2-21Z (VAX)
UCX$INTERNET_SERVICES_V6_SEC.EXE UCX V4.2-21Z (VAX)

Problem:

UCX small buffers are never deallocated when creating and
deleting SLIP interfaces (actually any multicast-capable
interfaces). After some days the max value is reached.

Solution:

Deallocate the multicast address buffers that get
allocated each time an interface is defined.

Reference:

PTR 70-5-676 / CFS.57541 / EVT102495

Maybe not applicable?

[Ian Miller.]

UCX V4.2 ECO 5

ftp://ftp.itrc.hp.com/archived_patches/openvms_patches/axp/7.X/v7.0/tcpip/4.2/dec-axpvms-ucxeco_42_5-v0400--4.README

ftp://ftp.itrc.hp.com/archived_patches/openvms_patches/axp/7.X/v7.0/tcpip/4.2/dec-axpvms-ucxeco_42_5-v0400--4.pcsi-dcx_axpexe

[Volker Halle]

Steve,

the no. of sockets used is certainly reason for concern. Does UCX SHO DEV show lots of BG devices ? Still with active connections ? Which processes do they belong to (SHO DEV/FUL BGxxx) ?

Volker.

[Volker Halle]

Steve,

is this a 'deja vu' event ?

See:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=826950

from 3-MAR-2005. If this is the same system, you were at 300 sockets at that time, now you're at 900.

More than just a coincidence ?

Volker.

[Arch_Muthiah]

Steve,

find some more info from this similar thread discussed earlier...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=960393


Archunan

[Arch_Muthiah]

Steve,

I see there is 'wait' in your small buffer.
so you have increased your small buf to 2000 max.
After this (stop/starting telnet service) have you seen ucx show comm/mem?.Make sure there is no 'wait', if there is any wait, that means still you have exceeded your small buffer, so you have to increase small buf value more.


Archunan