# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

If the default values are not appropriate for your network configuration, follow these guidelines:

- Change the default values only if necessary. They produce:
  - 20 clusters of small MBUFs
  - 20 clusters of large MBUFs
- If you must change the defaults:
  - For a large system with large memory, specify a larger maximum value.
  - For a small system, try a smaller maximum value.

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

### A.2.3.4 Dynamically Allocated MBUFs

If they are needed, UCX dynamically allocates additional MBUFs, as follows:

- UCX calculates the number with this equation:
  Dynamic MBUFs Available = [MAX MBUFs - preMBUFs]
- When maximum space is reached, UCX does one of the following:
  - Temporarily puts the request in the internet wait-for-resource state
  - Denies and aborts the request
- The total maximum number of MBUFs also depends on the free nonpaged memory on your system, which you can monitor.

## A.2.4 Device Sockets

A device socket is an OpenVMS pseudodevice plus a socket. UCX supports three device socket types:

- DGRAM
- RAW_IP
- STREAM

Buffer space is affected by device sockets as follows:

- The socket is allocated from the control buffer pool (small buffers).
- A device socket requires approximately 1280 bytes of nonpaged pool.
- The default maximum number of sockets is 300.
- The default maximum number of nonpaged bytes for the device sockets is 384,000 bytes (300 * 1280 = 384,000).

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.

Table A-5 Channel-Assigning to Internet Pseudodevices
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:

- SET COMMUNICATION
- SET CONFIGURATION COMMUNICATION

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:

- SHOW DEVICE_SOCKET device_socket /FULL
- SHOW DEVICE_SOCKET /SERVICE=service /FULL
- SHOW PROTOCOL TCP

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.

Table A-6 SHOW DEVICE_SOCKET Command: Counters
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.

- SHOW PROTOCOL TCP displays statistics.
- SHOW PROTOCOL TCP /PARAMETERS displays the current configuration.

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.

Table A-7 SHOW PROTOCOL Display
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:

- I/O flags
- I/O flags counters
- Application option settings
- State of the service
- Counters for receiving and sending buffers

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

### A.2.4.1 Terminating TCP Connections

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

## A.2.5 Checksum Calculations

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:

1. Monitor the number of dropped packets because of a bad checksum. Issue:

       UCX> SHOW PROTOCOL protocol

   or

       UCX> SHOW PROTOCOL

   For example:

       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:

2. If the counter for dropped packets is low, disable the checksum calculations.

   > Note

   > If you disable the TCP Send Checksum, you can communicate only with hosts that have a disabled TCP Receive Checksum.

   Issue one of these commands:

       UCX> SET PROTOCOL IP /NOCHECKSUM
       UCX> SET PROTOCOL TCP /CHECKSUM=(NORECEIVE,NOSEND)
       UCX> SET PROTOCOL UDP /CHECKSUM=(NORECEIVE,NOSEND)

3. If performance improves, make the new settings permanent. Issue:

       UCX> SET CONFIGURATION PROTOCOL IP /NOCHECKSUM
       UCX> SET CONFIGURATION PROTOCOL TCP /CHECKSUM=(NORECEIVE,NOSEND)
       UCX> SET CONFIGURATION PROTOCOL UDP /CHECKSUM=(NORECEIVE,NOSEND)

# A.3 General Problems

If a user cannot gain access to a service, use the following troubleshooting techniques:

- Verify the availability of the service. Section A.3.1
- Verify connectivity. Section A.3.2
- Analyze the service. Section A.3.3

## A.3.1 Verifying Availability

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:

1. Check the identifiers in the OpenVMS Authorize facility to ensure that the accounts have been created properly.
2. If you need to re-create accounts:
   1. Delete all of the existing UCX identifiers and accounts.
   2. Rerun UCX$CONFIG.COM.

## A.3.2 Checking Connectivity

When communication fails, try to isolate the problem with these steps:

1. Use the PING (or LOOP) command to test the connectivity between the systems.
2. If the command fails, check your hardware network connections and your internet parameters.
3. Check that the network and broadcast masks are correct for your interface.
4. Check that the host addresses are correct in the hosts database.

## A.3.3 OPCOM Messages

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:

1. Searches the services database for invalid definitions that include records for protocol options, but lack a header record
2. Displays the invalid records, if it finds any
3. Deletes the invalid records, if you specify the /REPAIR qualifier

Use ANALYZE SERVICE if the following apply:

- You try to execute the SET SERVICE command to add a new service.
- You get a "duplicate record" error.
- The SHOW SERVICE command fails to identify the problem.

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:

- Name of the service's startup command file
- Number if the port that the service will use
- Name of the service's process
- User account information matching the information in the system user authorization file (SYSUAF.DAT)

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:

1. Stop the BIND Server.
2. Manually add the missing names.
3. Update the Start Of Authority (SOA) records.
4. Restart the BIND Server.

## A.4.2 BIND Server Load Balancing

UCX provides the following tools to help troubleshoot the BIND server load balancing function.

- System logical names (see Section A.4.2.1)
- Metric View utility (see Section A.4.2.2)

### A.4.2.1 Logical Names

Use the following system logical names for troubleshooting:

- UCX$BIND_METRIC_DBG_LEVEL --- Turns on the diagnostics for the metric server.
  - Level 1 sets minimum diagnostics.
  - Level 2 sets increased diagnostics.
  - The log file is SYS$SPECIFIC:[UCX$BIND]UCX$BIND_METRIC_SERVER.LOG.
- UCX$BIND_CLUSTER_DBG_LEVEL --- Turns on the diagnostics related to cluster host queries and responses for debugging BIND server output for cluster load balancing.
  - Level 1 displays the cluster host entries and metric ratings.
  - Level 2 displays increased diagnostics.
  - The log file is SYS$SPECIFIC:[UCX$BIND]UCX$BIND_STARTUP.LOG.

> 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

### A.4.2.2 Metric View Utility

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:

- UCX$METRIC.EXE --- does the computing
- UCX$METRICVIEW.EXE --- reads the metric ratings

To run Metric View, issue:

    $ MCR UCX$METRICVIEW /HOST=cluster_host -
    _$ [ /USER=remote_user ] [ /PASS=remote_passwd ]

# A.5 BOOTP

Most problems with BOOTP are due to:

- Inaccurate information in the BOOTP database
- Directory access restrictions because the UCX$BOOTP user account is unprivileged
- File access restrictions because the UCX$BOOTP user account is unprivileged

If BOOTP fails to respond to a client request, follow these steps:

1. Verify the accuracy of the information in the BOOTP database for that client, especially the hardware address and image file name.
2. Verify the directory and file access to the image file.
3. Turn on logging.

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 the following logical names in the system logical name file:

      $ DEFINE /SYSTEM UCX$BOOTP_TRACE 1

      $ DEFINE /SYSTEM UCX$BOOTP_EXTLOG 1

- If BOOTP is running, stop the process and restart it.
- Remove these logical names as soon as the problem is fixed. On a busy network with frequent BOOTP requests, the log file can rapidly consume large amounts of space on your system disk.

# A.6 TFTP

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.

- Use the UCX$TFTP_EXTLOG logical name to help trace file-transfer failures.
- Ensure that the TFTP server has access to directories and files. Set protections accordingly.
- Create the target files to enable TFTP to reply to upline dump requests, for example, write (WRQ) requests.

## A.6.1 Monitoring Client Activity

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

## A.6.2 Monitoring the TFTP Process

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

# A.7 FTP

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:

1. FTP calls RMS to create the file.
2. RMS creates the file with the system's default for number of blocks to be allocated (ALQ value).
3. If the file being copied is larger than the space originally allocated, RMS extends the space by adding blocks of memory space.
4. The number of extension blocks is determined by the system's RMS default extension quantity (DEQ value).

Previous | Next | Contents