If the default values are not appropriate for your network configuration, follow these guidelines:
Example:
This command permanently sets up, in the configuration database, the
clusters on a large system, allocating 30 control clusters (1500
divided by 50) of small MBUFs and 20 data clusters (300 divided by 15)
of large MBUFs.
UCX> SET CONFIGURATION COMMUNICATION /LARGE_BUFFERS=(MIN=15,MAX=300) - _UCX> /SMALL_BUFFERS=(MIN=50,MAX=1500) /IRP=MAX=300
The following table lists the highest valid number of buffers per cluster, which you set with the MINIMUM option.
MINIMUM: | Ethernet | FDDI |
---|---|---|
/SMALL_BUFFERS= | 127 | 127 |
/LARGE_BUFFERS= | 31 | 12 |
If they are needed, UCX dynamically allocates additional MBUFs, as follows:
A device socket is an OpenVMS pseudodevice plus a socket. UCX supports three device socket types:
Buffer space is affected by device sockets as follows:
An OpenVMS process using TCP/IP protocols requires that a channel be assigned to an internet pseudodevice (UCX$DEVICE or BG0:). Table A-5 shows the results when channels are assigned and deassigned.
When an OpenVMS process... | The result is... |
---|---|
Assigns a channel to an internet pseudodevice: |
An internet pseudodevice is created.
A data structure, called a socket, is allocated for it. |
Deassigns the channel: |
The device is deleted.
The socket is deallocated. |
To increase the maximum number of device sockets, issue one of these commands:
To monitor device socket usage, use the SHOW COMMUNICATION command with the /MEMORY and /FULL qualifiers. For example:
UCX> SHOW COMMUNICATION /MEMORY /FULL MBUF Type: Small_static Free 10 Total buffers 50 Header 4 Socket 17 Prot. control 12 IP address 2 Data 0 Socket name 0 Socket options 0 Fragment reassembly 0 Route 3 Size of cluster 13056 MBUF Type: Large_static Free 10 Total buffers 10 Header 0 Socket 0 Prot. control 0 IP address 0 Data 0 Socket name 0 Socket options 0 Fragment reassembly 0 Route 0 Size of cluster 47616 UCX>
For help with a problem, examine the information displayed by these commands:
Example 1:
This command displays information about DEVICE_SOCKET BG8844.
UCX> SHOW DEVICE_SOCKET BG8844 /FULL Device_socket: bg8844 Type: STREAM LOCAL REMOTE Port: 513 1021 Host: loon.lake.org HERON.SEA.ORG Service: RLOGIN Terminal: TNA42: RECEIVE SEND Queued I/O 0 0 Q0LEN 0 Socket buffer bytes 0 0 QLEN 0 Socket buffer quota 3000 3000 QLIMIT 0 Total buffer alloc 0 0 TIMEO 0 Total buffer limit 12000 12000 ERROR 0 Number of XONs 0 0 OOBMARK 0 Number of XOFFs 0 0 I/O completed 2 29 Bytes transferred 30 1367 Options: REUSEADR KEEP OOBINLINE State: ISCONNECTED PRIV RCV Buff: SEL SND Buff: SEL
Table A-6 gives the meanings of the counters in the first column.
Counter Name | Meaning |
---|---|
Q0LEN | Number of sockets that are about to be connected to the specified socket |
QLEN | Number of sockets that have established a connection but have not yet been accepted by the specified socket |
QLIMIT | Maximum number of sockets allowed in the QLEN or Q0LEN |
TIMEO | Not used |
OOBMARK | Out-of-band mark |
The value for the maximum number of device sockets affects the nonpaged pool. If you need to modify the maximum number of device sockets, issue the SET COMMUNICATION /DEVICE_SOCKETS=n command. The default is 300.
Examine the information displayed by the SHOW PROTOCOL TCP command.
Example:
This command displays TCP statistics.
UCX> SHOW PROTOCOL TCP TCP Connect initiated: 740 Connect accepted: 360 Connect established: 1079 Connect closed: 2085 Connect dropped: 44 Embry connect drop: 14 Attempt rtt: 50992 Succeeded rtt: 49782 XMT Delayed ACKs: 11671 Connect timeout: 7 ReXMT timeout: 853 Persist timeout: 21 Keepalive timeout: 32710 Keepalive probes: 28136 Keepalive drops: 10 Total XMT segments: 86202 XMT segments: 64039 XMT bytes: 30742698 XMT packet reXMT: 1233 XMT bytes reXMT: 810393 XMT ACK only: 17558 XMT window probes: 18 XMT URG only: 0 XMT wind update pack: 1338 XMT CTRL segments: 2016 Total RCV segments: 116627 RCV segments: 45846 RCV bytes: 5524331 RCV chksum error: 5 RCV bad offset: 0 RCV too short: 0 RCV dup only pack: 4076 RCV dup only bytes: 181858 RCV part dup pack: 40 RCV part dup bytes: 565 RCV bad order pack: 738 RCV bad order bytes: 17853 RCV pack after wind: 0 RCV bytes after wind: 0 RCV pack after close: 18 RCV window probes: 0 RCV dup ACKs: 29567 RCV ACK for unXMT: 0 RCV ACK segments: 52283 RCV ACK bytes: 30610592 RCV wind update pack: 562
Table A-7 lists the meanings of the display's abbreviations.
rtt | round-trip time measurement |
XMT | transmit |
reXMT | retransmit |
ACK | acknowledge |
URG | urgent |
RCV | receive |
CTRL | control |
chksum | checksum |
dup | duplicate |
Embry | embryonic connections (connections not yet established) |
wind | window |
For problems with a particular service, monitor the device sockets in use by that service. For example, to monitor device sockets used by the TELNET server, issue:
UCX> SHOW DEVICE_SOCKET /SERVICE=TELNET Device_socket Type Local Remote Service Host bg12 STREAM 23 0 TELNET 0.0.0.0 bg49 STREAM 23 1671 TELNET bluebird bg2055 STREAM 23 1672 TELNET blackcap bg3088 STREAM 23 1687 TELNET goldfinch UCX>
Use the /FULL qualifier to display:
Example 2:
This command shows all the available information about device socket
BG49, used by TELNET.
UCX> SHOW DEVICE_SOCKET BG49 /FULL Device_socket: bg49 Type: STREAM LOCAL REMOTE Port: 23 0 Host: 0.0.0.0 bluebird.org Service: TELNET RECEIVE SEND Queued I/O 0 0 Q0LEN 0 Socket buffer bytes 0 0 QLEN 0 Socket buffer quota 3000 3000 QLIMIT 5 Total buffer alloc 0 0 TIMEO 0 Total buffer limit 12000 12000 ERROR 0 Number of XONs 0 0 OOBMARK 0 Number of XOFFs 0 0 I/O completed 39 0 Bytes transferred 0 0 Options: ACCEPT REUSEADR KEEP State: PRIV RCV Buff: None SND Buff: None UCX>
Example:
This command displays TCP parameter settings.
UCX> SHOW PROTOCOL TCP /PARAMETERS TCP MTU size segment: disabled Delay ACK: enabled Loopback: disabled Drop timer: 600 Probe timer: 75 Receive Send Checksum: enabled enabled Push: disabled disabled Quota: 4096 4096
To terminate existing TCP connections, issue:
UCX> DISCONNECT DEVICE_SOCKET dev_sock_number
Example:
This command interactively terminates the TCP connection at device
socket BG123.
UCX> DISCONNECT DEVICE_SOCKET BG123
By default, a checksum calculation validates network data.
Checksums for large data packets require overhead that might impact performance. A way to improve performance is to disable checksum calculations.
Warning
Disabling checksums might cause data corruption to go undetected.
To disable checksums, follow these steps:
UCX> SHOW PROTOCOL protocol
UCX> SHOW PROTOCOL
UCX> SHOW PROTOCOL UDP UDP Bad header checksums: 0 Incomplete headers: 0 Bad data length fields: 0 Socket buffer drops: 83766 Unknown broadcast port drops: 1692483 Total received datagrams: 36225 Dropped:
Note
If you disable the TCP Send Checksum, you can communicate only with hosts that have a disabled TCP Receive Checksum.
UCX> SET PROTOCOL IP /NOCHECKSUM UCX> SET PROTOCOL TCP /CHECKSUM=(NORECEIVE,NOSEND) UCX> SET PROTOCOL UDP /CHECKSUM=(NORECEIVE,NOSEND)
UCX> SET CONFIGURATION PROTOCOL IP /NOCHECKSUM UCX> SET CONFIGURATION PROTOCOL TCP /CHECKSUM=(NORECEIVE,NOSEND) UCX> SET CONFIGURATION PROTOCOL UDP /CHECKSUM=(NORECEIVE,NOSEND)
If a user cannot gain access to a service, use the following troubleshooting techniques:
During the UCX configuration procedure, select the services you want to configure. Before the end of each component configuration, the procedure asks if you want to enable the service.
When you troubleshoot a service, verify that it is enabled. Issue SHOW SERVICE. For example:
UCX> SHOW SERVICE RLOGIN Service Port Proto Process Address State RLOGIN 513 TCP not defined 0.0.0.0 Enabled
If you notice discrepancies, follow these steps:
When communication fails, try to isolate the problem with these steps:
If access to a service fails, use the OPCOM messages to try to
determine the cause. Read the OPCOM messages that are generated when an
attempt is made to access the particular service.
A.3.4 Analyzing Services
If the services database appears to be corrupted, use the ANALYZE SERVICE command, which:
Use ANALYZE SERVICE if the following apply:
A service definition can contain up to three records: a header record and up to two protocol options records. If a definition has at least one such record, it must also have a header record. If it lacks the header record, you cannot define a new service that has the same combination of this required information:
If header information is missing, SHOW SERVICE does not display any of
the service information.
A.4 BIND Server
To solve BIND server problems, use the following techniques.
A.4.1 Server Not Responding
A missing client name in the BIND Server's database files results in lack of service to that client. If records that point to the name servers in a domain are missing from your server's database files, you might see:
%UCX-W-BIND_NOSERVNAM, Server with address 199.85.8.8 is not responding %UCX-E-BIND_NOSERVERS, Default servers are not available %UCX-W-NORECORD, Information not found -UCX-E-BIND_NOSERVERS, Default servers are not available
When the CONVERT/ULTRIX BIND /DOMAIN command creates the .DB files from the hosts database, it cannot detect the existence or names of name servers in a domain. Therefore, it cannot add these records to the .DB files.
To solve the problem, follow these steps:
UCX provides the following tools to help troubleshoot the BIND server load balancing function.
Use the following system logical names for troubleshooting:
Note
When you finish troubleshooting, turn off the diagnostic logical names that you defined. They might slow down performance and increase the size of the log files.
In the following example, the UCX$BIND_CLUSTER_DBG_LEVEL logical name is set to 1, and the host is running the BIND server.
(LNM$SYSTEM_TABLE) "UCX$BIND_CLUSTER_DBG_LEVEL" = "1" "UCX$BIND_DOMAIN" = "ucx.ern.sea.com" "UCX$BIND_RETRY" = "...." "UCX$BIND_SERVER" = "........" "UCX$BIND_SERVER000" = "77.88.208.100" "UCX$BIND_SERVER001" = "77.88.208.53" "UCX$BIND_SERVER002" = "77.88.208.10" "UCX$BIND_STATE" = "........" "UCX$BIND_TIMEOUT" = "...." "UCX$BIND_TRANSPORT" = "UDP" output log: SYS$SPECIFIC:[UCX$BIND]UCX$BIND_STARTUP.LOG $ set noon $ VerifyMode = f$verify(0) $ Exit 1 $! login.com for DEC TCP/IP Services Auxiliary service $ ! $ ! $ ! Copyright (c) Digital Equipment Corporation, 1993 $ ! All Rights Reserved. Unpublished rights reserved $ ! under the copyright laws of the United States. $ ! $ ! The software contained on this media is proprietary $ ! to and embodies the confidential technology of $ ! Digital Equipment Corporation. Possession, use, $ ! duplication or dissemination of the software and $ ! media is authorized only pursuant to a valid written $ ! license from Digital Equipment Corporation. $ ! $ ! RESTRICTED RIGHTS LEGEND Use, duplication, or $ ! disclosure by the U.S. Government is subject to $ ! restrictions as set forth in Subparagraph (c)(1)(ii) $ ! of DFARS 252.227-7013, or in FAR 52.227-19, as $ ! applicable. $ !+ $ ! $ ON CONTROL_Y THEN GOTO EXIT $ SET NOON $! $ data_directory = F$TRNLNM ("UCX$BIND_SERVER_DATA","LNM$SYSTEM") $ IF "" .EQS. "" THEN - data_directory = F$ENVIRONMENT("DEFAULT") $! $ DEFINE UCX$BIND_SERVER_DATA SYS$SPECIFIC:[UCX$BIND] $! $ IF F$SEARCH ("SYS$SPECIFIC:[UCX$BIND]*.log") .NES. "" THEN - PURGE /NOLOG /KEEP=4 SYS$SPECIFIC:[UCX$BIND]*.log $! $ image_directory = F$TRNLNM ("UCX$BIND_SERVER_IMAGES","LNM$SYSTEM") $ IF "" .EQS. "" THEN image_directory = "SYS$SYSTEM:" $! $ UCX$BIND_SERVER_XFER :== $ SYS$SYSTEM:UCX$BIND_SERVER_XFER.EXE $! $ RUN SYS$SYSTEM:UCX$BIND_SERVER.EXE UCX BIND Server Notice message -- Thu Jun 1 15:19:45 1997 restarted UCX BIND Server Notice message -- Thu Jun 1 15:20:58 1997 req: nlookup (MALLARD.ucx.ern.sea.com) type=1 cluster name: MALLARD.ucx.ern.sea.com CLUSTER HOST - RATING METRIC TABLE CLUSTER_HOST: 64d01410 RATING_METRIC: 37 CLUSTER_HOST: 26d01410 RATING_METRIC: 58 CLUSTER_HOST: 3ad01410 RATING_METRIC: 999999 CLUSTER_HOST: 30d01410 RATING_METRIC: 50 CLUSTER_HOST: 36d01410 RATING_METRIC: 20
Another troubleshooting tool is the Metric View utility, SYS$COMMON:[SYSEXE]UCX$METRICVIEW.EXE. Metric View displays the metric rating of the member hosts in the TCP/IP cluster.
Two images in the UCX distribution kit perform the metric functions:
To run Metric View, issue:
$ MCR UCX$METRICVIEW /HOST=cluster_host - _$ [ /USER=remote_user ] [ /PASS=remote_passwd ]
Most problems with BOOTP are due to:
If BOOTP fails to respond to a client request, follow these steps:
BOOTP ignores incoming requests from unknown clients, for example, clients that are not found in the BOOTP database. Therefore, it might be difficult to identify the reason for failing to service incoming requests.
By default, BOOTP does not generate logs despite the fact that SYS$SYSDEVICE:[UCX$BOOTP]UCX$BOOTP_STARTUP.LOG contains a log file. If you turn on logging, the log displays the client hardware address for every incoming BOOTP request, as well as the information used in a response to those requests, if any. With this information, you can detect whether or not the server sees a particular client request. Follow these steps:
$ DEFINE /SYSTEM UCX$BOOTP_TRACE 1 $ DEFINE /SYSTEM UCX$BOOTP_EXTLOG 1
The TFTP server runs as an unprivileged user on your system. It is restricted to accessing only files or directories that OpenVMS file system security measures allow. Verify that the boot files have the appropriate protection and ownership so that the TFTP server has access to them.
The TFTP server does not log incoming file transfer requests. However, you can log initial requests from clients. Each message includes the IP address of the requesting client, the date, and time of the request. Requests that fail and the reason are also logged.
This log file, SYS$SYSDEVICE:[UCX$TFTP]UCX$TFTP_STARTUP.LOG, can be useful for troubleshooting TFTP transfer failures. To log initial client requests. set the following system logical name. Issue:
$ DEFINE /SYSTEM UCX$TFTP_EXTLOG n
When you have fixed the problem, deassign the logical name because it can create a large log file.
Example:
With this command, TFTP logs one message for each incoming read (RRQ)
or write (WRQ) request.
$ DEFINE /SYSTEM UCX$TFTP_EXTLOG 1
To monitor TFTP, use the SHOW SERVICE TFTP and SHOW SERVICE TFTP /FULL commands.
Example:
These commands show values that are either defaults or were previously
set with SET SERVICE TFTP.
UCX> SHOW SERVICE TFTP Service Port Proto Process Address State TFTP 69 UDP UCX$TFTP 0.0.0.0 Enabled UCX> SHOW SERVICE TFTP /FULL Service: TFTP State: Enabled Port: 69 Protocol: UDP Address: 0.0.0.0 Inactivity: 5 User_name: UCX$TFTP Process: UCX$TFTP Limit: 1 Active: 1 Peak: 1 File: SYS$SYSDEVICE:[UCX$TFTP]UCX$TFTP_STARTUP.COM Flags: Listen Socket Opts: Rcheck Scheck Receive: 0 Send: 0 Log Opts: Acpt Actv Dactv Conn Exit Logi Mdfy Rjct TimO File: SYS$SYSDEVICE:[UCX$TFTP]UCX$TFTPD_STARTUP.LOG Security Reject msg: not defined Accept host: 0.0.0.0 Accept netw: 0.0.0.0
You can improve FTP performance for end users who transfer large files
from non-UCX systems to hosts running UCX.
A.7.1 FTP Performance
Large file transfers can impact FTP performance. A file transfer consists of the following events: