# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

The first command immediately changes the running system. The second causes the services to be enabled the next time UCX starts up. Before transferring data, a client and a server initialize several communication operations. Initialization is determined by the socket type and activation flags set in the services database. Table 1-2 describes the communication initialization process.

Table 1-2 Communication Initialization Variables
Variable | Option | Description
--- | --- | ---
Socket Type | STREAM | When initializing data communications for a STREAM socket, the server listens on a socket for a connection request. When a connection request is accepted, the new socket (which results from accepting the connection) is made available for network data transfer.
| DATAGRAM | This is a connectionless socket. No particular operation is required at initialization before data transfer. Therefore, an incoming datagram can be read directly, once the server socket exists and its characteristics are defined.
Activation Flags | LISTEN | The flag is set with the /FLAGS qualifier of the SET SERVICE command. The auxiliary server starts the network process after data communication initialization. The server is able to start data communication directly on a socket that is passed at the logical name SYS$NET without any additional operations (other than $ASSIGN or a DEC C socket call). There is no need for communication initializations (connect, listen, or accept). This allows servers developed on UNIX to be ported with minimal effort. Also, multiple copies of a single-threaded server can run without any modification, allowing parallel processing of multiple requests.
| NOLISTEN | The auxiliary server creates a network process and starts the requested services after receiving a network request. UCX does not initialize data communication. Therefore, the server for the requested service must initialize its own data communication. If a server is started with the NOLISTEN activation flag, it can listen for more service requests and process them as soon as they come. Use this function to terminate a server started with the NOLISTEN activation flag. Specify the idle time with the /INACTIVITY_TIMER qualifier of the SET SERVICE command. Note: This flag is reserved. Use only under guidance of your DIGITAL support representative.

The auxiliary server does not transfer data. Therefore, the auxiliary server can set socket options for a requested service either before or during data communications. Some available options are:

- KEEPALIVE and LINGER for TCP communications
- BROADCAST for UDP communications

You can also specify socket options for a requested service in the services database. These socket options are set before the new socket is passed to the requested server.

## 1.4.5 Setting Up Event Logging

Event logging can help you manage the UCX software. By default, UCX services do not log events but you can enable event logging for all or selected configured services. You can configure UCX to log events to the operator's console, a log file, or both. To set up event logging, issue the following commands:

- To specify event logging for one service:
  SET SERVICE service /LOG_OPTIONS=(FILE=file,options)
  This configuration is overridden by the values set with the /FORCE_LOG_OPTIONS qualifier of the SET COMMUNICATION and SET CONFIGURATION COMMUNICATION commands.
- To interactively set event logging affecting all the services:
  - SET COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Provides an alternate way to capture logging that you did not set up with the SET SERVICE service /LOG command. Specifies options that, when set, apply to all the services.
  - SET COMMUNICATION /FORCE_LOG_OPTIONS=options
    /FORCE_LOG_OPTIONS overrides the settings of the SET SERVICE /LOG_OPTIONS command.
- To permanently set event logging affecting all the services:
  - SET CONFIGURATION COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /ALLOW_LOG_OPTIONS
  - SET CONFIGURATION COMMUNICATION /FORCE_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /FORCE_LOG_OPTIONS

For a list of all the logging options, see the SET SERVICE command description in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

Some UCX components provide additional event logging capabilities. Refer to individual component chapters for more information.

# 1.5 UCX and Memory Management

UCX stores user data in the OpenVMS system space (nonpaged pool). The amount of nonpaged pool space required depends on your network configuration. UCX allocates the following buffer space from the OpenVMS nonpaged pool:

- Buffers specific to OpenVMS (internet I/O request packets [IRPs] and large request packets [LRPs])
- Buffers for the internet memory buffers (MBUFs) and device sockets (see Table 1-3)

Table 1-3 Default Buffer Sizes
Default MBUFs Used by UCX | Number of Bytes
--- | ---
Small buffers | 256
Large buffers for Ethernet-only hosts | 1792
Large buffers for FDDI hosts | About 4500

UCX preallocates MBUFs in blocks as follows:

- Control clusters that store information related to:
  - Device sockets
  - Internal control structures
  - IP addresses
  - IP routes
  - IP packet headers
- Data clusters that store the data in the system space as follows:
  - Before actual transmission, a transmit data operation moves data from the user process space to the large buffer.
  - Until a user process is ready to read data, a receive data operation stores received data in the large buffers.

Table 1-4 provides the initial (default) values UCX allocates to control cluster (small MBUFs) and data clusters (large MBUFs).

Table 1-4 Default MBUF Allocation
Buffer | Default Value
--- | ---
Control clusters | /SMALL_BUFFERS=MIN=50
| /SMALL_BUFFERS=MAX=1000
Data clusters | /LARGE_BUFFERS=MIN=10
| /LARGE_BUFFERS=MAX=200

If the default values are not appropriate for your network, you can modify them. See Appendix A for further instructions.

UCX sets buffers for the following data:

- Receive buffer
- Send buffer
- Socket buffer

Each buffer is assigned a quota. When the UCX receive buffer quota is reached, UCX discards any messages received for a particular device socket. When the send buffer quota is reached, UCX puts the process in a resource WAIT. If a process is configured with a NOWAIT option, it receives an I/O error on the write request that filled the buffer quota.

# 1.6 Obtaining Network Activity Statistics

UCX uses counters indicating real-time statistics of usage, performance, and errors. Counters show the amount of specific network activities. To display them, issue SHOW commands. For example, the following command displays, for the UCX communication buffers, the amounts of memory used and free.

    UCX> SHOW COMMUNICATION /MEMORY
                                                                    MBUF Summary
            Small_static    Large_static    Small_dynamic     Large_dynamic
    Total  buffers             50            10             50              0
    Free                        2            10             27              0
    Busy
      Data                      0             0              0              0
      Header                    6             0              8              0
      Socket                   22             0              7              0
      Prot.  control           14             0              8              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               3             0              0              0
    Size  of  cluster       13056         19136          13112              0

                    Free   Current         Peak          Waits          Drops
    Small  Buffers              70          123              0              0
    Large  Buffers               0           48              0              0
    IRPs              7          0            1              0              0
                    Small  clusters  Large  clusters    Non  UCX  buffers
    Free                         1            2              0

For more information about using counters to monitor usage and network activity, see Appendix A.

# Chapter 2
Configuring the Interface

OpenVMS systems running DIGITAL TCP/IP Services for OpenVMS (UCX) communicate with other internet hosts over a variety of physical media¹. Because TCP/IP is independent of the underlying physical network, IP addresses are implemented in the network software, not the network hardware.

This chapter reviews key concepts and explains how to configure the network interface and assign IP addresses, subnet masks, and broadcast addresses.

### Note

#### ¹ See the DIGITAL TCP/IP Services for OpenVMS Software Product Description for a complete list of supported media.

# 2.1 Reviewing Key Concepts

A network controller is the hardware connection between a computer system and a physical network. Controllers perform the packet channeling to and from the physical medium of your network, usually a cable.

The network interface is a logical network controller --- a software component that communicates with your UCX software and the network controller. UCX supports multiple logical interfaces for each physical network controller. This means a single physical connection can have more than one IP address. The network controller must be configured to make it visible to the network software. Then the logical network interface can be configured using the device_name, logical_unit_number format.

For each interface, you can enable or disable the interface; set the subnet mask; set protocols for the interface; and assign IP, Ethernet and broadcast addresses.

# 2.2 Configuring Network Controllers

If you used UCX$CONFIG to configure your software, UCX automatically recognizes network controllers upon startup. If you need to add new network controllers to your system after installing and configuring UCX, follow the installation and configuration instructions that come with your hardware, then simply rerun UCX$CONFIG. UCX will recognize the new controller the next time the software starts up.

> Important

> Hardware installation and configuration instructions are specific for the various network controllers --- be sure to read the instructions provided with your new hardware before installing.

To display current controller definitions, issue the LIST COMMUNICATION_CONTROLLER command. It lists the names and other information about the communication controllers known to UCX. For example,

    UCX>  LIST COMMUNICATION_CONTROLLER

                        Communication Controller Configuration

    Controller:  LO   Internet Interface:  L
                             Description:
                                    Type:  LOCAL

    Controller:  XE   Internet Interface:  D
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  EF   Internet Interface:  F
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  ET   Internet Interface:  N
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  XQ   Internet Interface:  Q
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  ER   Internet Interface:  R
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  FW   Internet Interface:  W
                             Description:
                                    Type:  CLUSTER FDDI

    Controller:  FA   Internet Interface:  A
                             Description:
                                    Type:  CLUSTER FDDI
    Controller:  IR   Internet Interface:  R
                             Description:
                                    Type:  CLUSTER TOKEN_RING

    Controller:  SL   Internet Interface:  S
                             Description:
                                    Type:  SERIAL

    Controller:  EO   Internet Interface:  O
                             Description:
                                    Type:  CLUSTER ETHERNET

    Controller:  PP   Internet Interface:  P
                             Description:  PPP
                                    Type:  Serial

    Controller:  CL   Internet Interface:  I
                             Description:  ATM Classical IP
                                    Type:  FDDI

    Controller:  EL   Internet Interface:  L
                             Description:  ATM Emulated LAN
                                    Type:  FDDI

To manually add a new controller, issue the DEFINE COMMUNICATION_CONTROLLER command. To remove a controller definition, issue the DELETE COMMUNICATION_CONTROLLER command.

# 2.3 Configuring Network Interfaces

UCX supports one local interface for loopbacks and one or more network interfaces for each network controller.

The configuration procedure initially configures your network interfaces. Use the following commands if you need to redefine an interface or configure serial lines. See Chapter 3 for more information on configuring serial lines.

- SET INTERFACE
- SET NOINTERFACE
- SET CONFIGURATION INTERFACE
- SET CONFIGURATION NOINTERFACE

To display information, use the SHOW INTERFACE command, and to disable an interface, issue the SET NOINTERFACE command.

> Note

> If you are redefining an existing interface, issue the SET NOINTERFACE command before you issue the SET INTERFACE command.

## 2.3.1 Specifying the Interface

On the SET INTERFACE command line, the interface parameter is the interface name for the communication controller you are configuring. Some examples are: FZ0, FZ1, FR1, IR1, EZ0, EX0, SL0, SL1, SL2.

The name of a network interface has two characters followed by the unit number of the communication controller, conforming to this pattern:

Controller | Unit Number
--- | ---
First controller | 0
Second controller | 1
Third controller | 2

## 2.3.2 Specifying the Network Mask

An IP address consists of a network number and a host number. The network mask is the part of the host field of the IP address identified as the subnetwork. Every host on the same network must have the same subnetwork mask. To specify the network mask, use the /NETWORK_MASK qualifier. This is required if you use subnetworks.

UCX calculates the default by setting:

- The bits representing the network fields---to 1
- The bits representing the host field---to 0

You can also divide the host field into a site-specific subnetwork and host field. For more information about defining network interfaces for subnet routing, see Section 4.4.1.

# 2.4 Manually Configuring a Hardware Address

Network hosts require manual configuration of a hardware address for a remote IP address under the following conditions:

- The remote host does not support the Address Resolution Protocol (ARP). You need static mapping of IP addresses to hardware addresses.
- The remote host is running ARP, but a change was made to the internet interface on that host.
  To allow the change to be made known to your system, flush the address mapping tables. Use the SET NOARP command.

For example, to map the Ethernet address AA-02-04-05-06-07 of host ROOK, follow these steps:

1. Add the hardware address to the ARP table. Issue:

       UCX> SET ARP AA-02-04-05-06-07 ROOK

2. Specify the time interval for ARP to hold the information in its cache, for example, 30 minutes. Enter this information into dynamic memory and into the permanent configuration database. Issue:

       UCX> SET PROTOCOL ARP /COMPLETE_TIMER=30

       UCX> SET CONFIGURATION PROTOCOL ARP /COMPLETE_TIMER=30

   To set the maximum time that an unresolved query is kept in the ARP dynamic database, use the /INCOMPLETE_TIMER qualifier.

# Chapter 3
Configuring Serial Lines

A serial connection is made between two systems using modems and telephone lines or other serial lines. DIGITAL TCP/IP Services for OpenVMS supports serial connections using the PPP and SLIP (including CSLIP) protocols¹. You can use any standard OpenVMS terminal device as a PPP or SLIP line.

After establishing a Point-to-Point Protocol or Serial Line IP connection between hosts, you can run TCP/IP commands over the line. If the remote system is configured as a gateway to a network, local users can also reach other systems on that network through the serial connection.

This chapter reviews key concepts and describes how to configure your network interface to use a telephone circuit or other serial line.

### Note

#### ¹ PPP is available for OpenVMS V7.1 Alpha systems only.

# 3.1 Reviewing Key Concepts

If your OpenVMS system is part of a large network, you will probably use both PPP and SLIP for your serial connections. An internet standard, PPP is often preferred because it ensures interoperability between systems from a wide variety of vendors. PPP provides a way for your OpenVMS Alpha system to establish a dynamic IP network connection over a serial line without the extensive use of additional router or server hardware.

However, SLIP has been in use for a longer period of time and thus is available for more kinds of hardware. SLIP is available for most terminal servers and in most PC implementations of TCP/IP. Because SLIP and PPP do not interoperate, hosts wishing to communicate must use the same protocol. For example, if your terminal server supports only SLIP, remote hosts that connect through this server must also use SLIP.

## 3.1.1 Uses for PPP and SLIP

One of the largest applications for IP over serial lines is dialup access. With this type of configuration, your OpenVMS host answers calls and establishes a connection initiated by a user on a remote host or PC. Or, users on your host can originate the dialup connection to a remote host or terminal server running the same protocol.

Dedicated serial lines running PPP or SLIP can also be used to connect separate LANs into a single WAN. In such a configuration, the host at each end of the serial connection is always the same; no other hosts are allowed to connect to either serial device.

## 3.1.2 Assigning an IP Address to Your PPP or SLIP Interface

Every network interface requires a unique IP address. If you configure PPP interfaces for multiple remote hosts, the remote hosts can obtain their IP addresses from your host when they connect. Similarly, you can configure a PPP interface on your system without knowing your own IP address and obtain it when you connect to a remote system.

Before establishing SLIP communcation with a remote host, however, you must obtain the IP address for the host's serial interface and assign IP addresses for each interface you configure on the local host.

When using SLIP, consider placing each serial line in a separate subnetwork. You accomplish this by assigning the same subnet mask for the interfaces at either end of the link.

If you need to use an address in the same subnetwork as your site LAN, use the proxy Address Resolution Protocol (ARP) feature (see Section 3.3.4).

## 3.1.3 Serial Line Internet Protocol

SLIP sends a datagram across the serial line as a series of bytes. It uses the special characters described below to mark when a series of bytes should be grouped together.

Character | Function | Hex Value | Decimal Values
--- | --- | --- | ---
END | Marks the end of the datagram. When the receiving SLIP encounters the END character, it knows that it has a complete datagram. | C0 | 192
ESC | Used to "escape" the SLIP control characters. | DB | 219

SLIP starts by sending an END character. If END is encountered within the datagram as data, SLIP inserts an escape character, sending the two-character sequence DB DC instead. If the ESC character appears within the datagram as data, it is replaced with the two-character sequence DB DD. The datagram ends with the END character after the last byte in the packet has been transmitted.

There is no standard SLIP specification, nor a defined maximum packet size for SLIP. DIGITAL's implementation of SLIP accepts 1006-byte datagrams and does not send more than 1006 bytes in a datagram.

Compressed SLIP provides header compression which is beneficial for small packets and low-speed serial links. Header compression improves packet throughput. You can enable CSLIP by means of the /COMPRESS qualifier when you issue a SET INTERFACE command. See Table 3-3 for more information.

Previous | Next | Contents