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.
| 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:
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:
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:
| 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:
Table 1-4 provides the initial (default) values UCX allocates to control cluster (small MBUFs) and data clusters (large MBUFs).
| 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:
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.
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.
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.
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.
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 |
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:
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:
For example, to map the Ethernet address AA-02-04-05-06-07 of host ROOK, follow these steps:
UCX> SET ARP AA-02-04-05-06-07 ROOK
UCX> SET PROTOCOL ARP /COMPLETE_TIMER=30 UCX> SET CONFIGURATION PROTOCOL ARP /COMPLETE_TIMER=30
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.
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.