# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

To check if cluster definitions exist, issue the SHOW CONFIGURATION BIND command.

Example:
In the following display, the SHOW CONFIGURATION BIND command shows one defined cluster, emu.bigbird.com. Because this load balancing cluster is defined, round-robin scheduling is not performed; cluster load balancing will be used instead.

    UCX> SHOW CONFIGURATION BIND

    Cluster:      emu.bigbird.com

    Primary
      Domain:     0.0.127.IN-ADDR.ARPA          File: NAMED.LOCAL

    Secondary
      Domain:     UCX.ERN.SEA.COM               File: UCX_ERN_SEA_COM.DB
      Host:       9.20.208.53

    Secondary
      Domain:     208.20.9.IN-ADDR.ARPA        File: 208_20_9_IN-ADDR_ARPA.DB
      Host:       9.20.208.53

    Cache
      Domain:     .            File: NAMED.CA
    UCX>

## 5.5.2 Cluster Load Balancing

UCX provides a configurable load balancing feature for load balancing clusters. This feature can be used by any application that wants to distribute a load across several systems.

When a client's request for a name translation of the load balancing cluster arrives, the BIND server returns the list of IP addresses, sorted with the least-loaded member first. This node has the highest metric value.

The host to which a connection is made depends on the dynamic metric value of the host and its availability.

To enable cluster load balancing, complete the following tasks:

- Ensure that all hosts in the cluster are running DIGITAL TCP/IP Services for OpenVMS.
- Define a load balancing cluster name in the UCX configuration database.

      SET CONFIGURATION BIND /CLUSTER=cluster_name

- Ensure that the BIND server is authoritative for the domain of which the cluster is a member.
- Ensure that there is TCP/IP connectivity between the cluster members and the BIND server.
- Run the metric server on each member of the cluster. Run UCX$CONFIG and select Metric Server from the Server Components menu.

Review the following guidelines:

- Cluster hosts and clients are not required to be on the same bridged LAN.
- There is no limit to the number of member hosts per cluster, but DIGITAL suggests no more than 100.
- A BIND server can also be a cluster member host.

To configure a BIND server to perform cluster load balancing, follow these steps:

1. Define cluster names. Issue:

       UCX> SET CONFIGURATION BIND /CLUSTER=cluster_name

   This information tells the BIND server that the name of the cluster is within the zone that this server serves and that cluster members are defined in SYS$SPECIFIC:[UCX$BIND]UCX_ERN_SEA_COM.DB.
   Perform this step on all authoritative (primary and secondary) servers for this zone.
2. Stop and restart UCX.

The following display shows a sample SHOW CONFIGURATION BIND display for a primary server with the cluster directive mallard.

    cluster       mallard.ucx.ern.sea.com

    Primary
      Domain:     0.0.127.IN-ADDR.ARPA          File: NAMED.LOCAL

    Primary
      Domain:     UCX.ERN.SEA.COM               File: UCX_ERN_SEA_COM.DB

    Primary
      Domain:     208.20.9.IN-ADDR.ARPA        File: 208_20_9_IN-ADDR_ARPA.DB

    Cache
      Domain:     .                             File: NAMED.CA

The following example shows a sample SHOW CONFIGURATION BIND display for a secondary server with the mallard cluster directive.

    cluster       mallard.ucx.ern.sea.com

    Primary
      Domain:     0.0.127.IN-ADDR.ARPA          File: NAMED.LOCAL

    Secondary
      Domain:     UCX.ERN.SEA.COM               File: UCX_ERN_SEA_COM.DB
      Host:       9.20.208.39

    Secondary
      Domain:     208.20.9.IN-ADDR.ARPA        File: 208_20_9_IN-ADDR_ARPA.DB
      Host:       9.88.208.39

    Cache
      Domain:     .                             File: NAMED.CA

The following example is an updated domain.DB file called SYS$SPECIFIC:[UCX$BIND]UCX_ERN_SEA_COM.DB. Edit this file to add the IP addresses of the cluster hosts.

> Important

> When you edit the file you must increment the serial number of the SOA record.

    $ORIGIN ucx.ern.sea.com.
    @               IN      SOA     owl.ucx.ern.sea.com. pmaster.owl.ern.sea.com.
    (
                                    24      ; Serial Number
                                    600     ; Refresh
                                    300     ; Retry
                                    172800  ; Expire
                                    43200 ) ; Minimum
    ;
                    IN      NS      owl.ucx.ern.sea.com.
                    IN      NS      condor.ucx.ern.sea.com.
    ;
    thrush          IN      A       9.20.208.53
    condor          IN      A       9.20.208.10
    birdy           IN      A       9.20.208.47
                    IN      MX      10 birdy.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    seagull         IN      A       9.20.208.30
                    IN      MX      10 seagull.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    owl             IN      A       9.20.208.72
                    IN      MX      10 owl.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    peacock         IN      A       9.20.208.73
                    IN      MX      10 pultdown.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    redwing         IN      A       9.20.208.79
                    IN      MX      10 redwing.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    robin           IN      A       9.20.208.47
                    IN      A       9.20.208.30
                    IN      A       9.20.208.72

    ;
    ;               cluster aliases for TCP/IP load balancing
    ;
    mallard.ucx.ern.sea.com        IN A     9.20.208.53
                                   IN A     9.20.208.54
                                   IN A     9.20.208.38
                                   IN A     9.20.208.100
    ; example cluster: puffin, lark22,thrush and oriole.

### 5.5.2.1 How Load Balancing Works

A client sends a host-name-to-address translation request. The receiving server processes the request and responds with the list of IP addresses, sorted with the least loaded member at the top of the list.

The BIND server calculates the load, called the metric rating, by exchanging UDP datagrams with the metric server software, running on each member. The following steps detail the communication:

1. The client (for example, TELNET) requests a name translation to start a session with a cluster.
2. The BIND server looks in the local cache that holds the cluster's hosts metric rating table.
3. If no metric rating information exists in the table, or if the information has expired, the server sends UDP requests to each cluster host.
   If the metric rating of a particular cluster host has not expired, the server saves the information.
4. The metric server running on each cluster host processes the requests from the BIND server and returns the current metric rating.
5. If a cluster host fails to respond to the request, this host's address is returned at the end of the list (either the host is not running or the metric service is disabled).
6. The BIND server sorts the list based on the least load (highest metric rating).
7. The client establishes a connection with the least loaded cluster host.

## 5.5.3 Using the Metric Server

The metric server computes the metric rating of the TCP/IP cluster members. To enable the metric server, run UCX$CONFIG or run SYS$MANAGER:UCX:METRIC_STARTUP.COM. To stop the metric server, run SYS$MANAGER:UCX$METRIC_SHUTDOWN.COM.

### 5.5.3.1 Load Computation

The metric server calculates the current load on a cluster host by examining the state of each of its processes. The server appropriately increments a counter, which is later scaled before being used in the load calculation. Scaling is based on:

- CPU power
- Free job slots
- Administratively set bias
- Available memory

### 5.5.3.2 Setting a Load Bias

To set a bias value, define the system logical name UCX$BIND_CPU_RATING. This factor represents the system manager's estimate of the relative CPU power. Its value can range from 1 for a low-power CPU to 100 for the highest-power CPU. To specify the default value, set the logical value to 0.

# 5.6 Using NSLOOKUP to Query a Name Server

NSLOOKUP is a debugging tool provided with BIND that allows anyone to directly query a name server and retrieve information. Use NSLOOKUP to determine if your local name server is running correctly or for retrieving information from remote servers.

NSLOOKUP makes direct queries to name servers around the world to obtain DNS information, including:

- Host names and addresses on the local domain
- Host names and addresses on remote domains
- Host names that server as MX mail exchangers
- Name servers for a specific zone

By default, NSLOOKUP queries for A records. Use the SET TYPE command to change the resource record type.

## 5.6.1 Starting and Stopping NSLOOKUP

Table 5-3 shows how to start and stop NSLOOKUP.

Table 5-3 NSLOOKUP Options
Action | Type This...
--- | ---
Run NSLOOKUP | $ RUN SYS$SYSTEM:UCX$NSLOOKUP.EXE
Terminate NSLOOKUP from within interactive mode | > exit
Terminate the current lookup activity | > Ctrl/z
Display online help | > HELP

You can put NSLOOKUP set commands in an initialization file, SYS$LOGIN:NSLOOKUPINIT.INI. The commands are executed when you start NSLOOKUP.

## 5.6.2 Guidelines for Using NSLOOKUP

The command line length must be less than 256 characters.

Unrecognized commands are interpreted as host names.

The NSLOOKUP tool is partly case-sensitive. It:

- Accepts lowercase
- Accepts uppercase
- Does not accept mixed case

## 5.6.3 NSLOOKUP Commands

When NSLOOKUP first starts, you see the name and address of the default BIND server, followed by the NSLOOKUP prompt. In the following example, the default server is purple.martin.eat.mosquitos.org.

    Default Server:  purple.martin.eat.mosquitos.org
    Address:  66.11.22.333

    >

You can enter the following commands.

- host [ server ]
  Looks up information using the current default server or using the server you specify. Enter the name of the host for which you need an IP address. For example, the following command searches for snowy.frozen.weather.com using the the default BIND server:

      > snowy.frozen.weather.com

  This command uses the server with IP address 128.45.45.40:

      > snowy.frozen.weather.com 128.45.45.40

- server domain
  Changes the default server to the domain you specify.
  The initial server used by lserver to look up information about domain.
  For a target host located in the server's domain, type the first (leftmost) label of the host's domain name. For example:

      > snowy 128.45.45.40

  The following command changes the default server, using the current default server to look up information for the new default server, 128.45.35.40:

      > server 128.45.35.40

- lserver
  Changes the default server. The following command changes the default server, using the initial default server to find information about 128.45.35.40:

      > lserver 128.45.35.40

- root
  Changes the default server for the root of the domain name space. Currently, the global community uses host ns.nic.ddn.mil. For example:

      > root snowy.frozen.weather.com

- ls
  Lists information about hosts in the domain you specify. The default output contains host names and their IP addresses. The option for ls are listed in Table 5-4.

  Table 5-4 Options to the NSLOOKUP ls Command
  Option | Function
  --- | ---
  -a | Lists aliases of hosts in the domain (CNAME entries)
  -d | Lists all the entries in the domain
  -l | Same as -d
  -h | Lists CPU and operating system information for the domain (HINFO entries)
  -m | Lists mail exchangers (MX) entries in the domain
  -s | Lists well known services (WKS) in the domain
  -t | Lists a specified entry type

  You can combine options, for example:

      > ls -msa

  The following example redirects the output from the screen to the file nslookup.temp in the current directory.

      > ls -a frozen.weather.com >> nslookup.temp

- help
  Prints a summary of the available commands.
- exit
  Exits NSLOOKUP.
- set
  Selects the type of information that NSLOOKUP displays. Table 5-5 lists the available options.

Table 5-5 Options to the NSLOOKUP set Command
Option | Function
--- | ---
ALL | Prints the current values of the options you can set as well as information about the current default server. For example:
    > set ALL
class= value | Changes the query class to one of the following: IN --- the Internet class (default) CHAOS --- the Chaos class ANY --- wildcard The class specifies the protocol group of the information. You can use the abbreviated form of the keyword cl. For example, this command tells NSLOOKUP to resolve both internet and chaos class queries (you can type INTERNET and CHAOS):
    > set class=ANY
querytype | Specifies the type of information you want. For example:
    > set querytype=A

    > set querytype=ANY
Valid types include
SOA | Start of Authority. Marks the beginning of a zone's data and defines parameters that affect the entire zone.
NS | Name Server. Identifies a domain's name server.
A | Address. Maps a host name to an address.
ANY | Defines all available resource records for a given name.
PTR | Pointer. Maps an address to a host name.
MX | Identifies where to deliver mail for a given domain.
CNAME | Defines an alias host name.
HINFO | Host Information. Describes a host's hardware and OS.
WKS | Well known service. Advertises network services.
[no]debug | Turns on debugging (default is nodebug). NSLOOKUP prints verbose information about the packet sent to the server and the answer. You can use the abbreviations nodeb and deb. For example:
    > set debug
[no]d2 | Returns all-inclusive debugging information (default is nod2). Prints all the fields of every packet. For example:
    > set d2
recurse | Tells the BIND server to contact other servers if it does not have the information you want. The servers carry out a complete (recursive) resolution for each query. For example:
    > set recurse
retry | Number of times that NSLOOKUP attempts to contact a BIND server if repeated tries fail. For example:
    > set retry=8
timeout | Length of time to wait for a reply from each attempt. For example:
    > set timeout=9
root= value | Changes the root server. For example, the following command changes the root server to ns.nasa.gov.
    > set root=ns.nasa.gov
root | Changes the default server to the new root server. For example:
    > root
ignoretc | Tells NSLOOKUP to ignore packet truncation errors. For example:
    > set ignoretc
domain name | Changes the default domain to the domain you specify. How the default domain name is appended to look up requests depends on the settings of the defname and search options. The domain search list contains the parents of the default domain if it has at least two components in its name. The default value is set in the UCX configuration database. To specify the default, type the abbreviation do. For example, if the default domain is CC.Berkeley.EDU, the search list is CC.Berkeley.EDU and Berkeley.EDU.
set srchlist | Specifies a different list. Use the set all command to display the list. The following command sets the default domain to cc.berkeley.edu. NSLOOKUP searches in cc.berkeley.edu and its parent domain berkeley.edu.
    > set domain=cc.berkeley.edu
srchlist= names | Changes the default domain name to the first name you specify and the domain search list to all the names you specify. Specify a maximum of six names separated by slashes (/). In the following example, the command sets the default domain to lcs.MIT.EDU and the search list to the three specified domains. It overrides the default domain name and associated search list for the set domain command.
    > set srchlist=lcs.MIT.EDU/ai.MIT.EDU/MIT.EDU
The default is the domain name specified in the UCX configuration database. The abbreviated form of the command is srchl.
[no]defname | Tells NSLOOKUP to append the default domain name to a nonfully-qualified ² DNS name lookup request. The abbreviated form is [no]def. For example, an NSLOOKUP query for the host rainy becomes rainy.cc.berkeley.edu.
[no]search | Tells NSLOOKUP to append the domain names in the search list to a non fully-qualified domain name ² lookup request. The default is search. The abbreviated form is [no]sea.

²A fully qualified domain name is a name that ends with a dot (.) as in host.domain.

# Chapter 6
Configuring BOOTP and TFTP

The Bootstrap Protocol (BOOTP) server answers network bootstrap requests from diskless workstations and other network devices such as routers, terminal servers, and network switching equipment. When it receives such a request, the BOOTP server looks up the workstation's address in the BOOTP database file.

The Trivial File Transfer Protocol (TFTP) handles the file transfer from a BOOTP server to a diskless client or other remote system. The client initiates the file transfer.

This chapter reviews key concepts and describes how to

- Create the BOOTP database and populate it with client entries
- Configure the BOOTP and TFTP processes
- Monitor the BOOTP and TFTP processes

# 6.1 Reviewing Key Concepts

The BOOTP server answers client requests for diskless client configuration by sending address and file name information to the client. When the client receives this information from the BOOTP server, it initiates a file transfer using the TFTP protocol.

Performing a network bootstrap consists of the following steps for the BOOTP server:

1. The BOOTP server receives a configuration request from a client. A broadcast request goes out to all potential servers on the subnetwork, or is directed to a predetermined known server address.
2. The BOOTP server reads the information in the BOOTP database to get information about the client. The identity of the client is based on the network hardware address contained in the request.
3. BOOTP identifies the network client.
4. BOOTP constructs a response that contains all of the information in the BOOTP database for that client. The types of information that the database stores are:
   - Client's IP address
   - Client's host name (usually)
   - Name and size of the client's system load file
   - IP address of the TFTP server storing this file
   - IP addresses of the hosts offering common network services, such as a log server or a print (LPD) server.
5. When the client receives the configuration information in the BOOTP response, it sends a request to the TFTP server host named in the response. This request is necessary only if the client must retrieve the load file.
6. If the client sends a read request (RRQ) to the TFTP server, it attempts to locate this file.
   If it finds the file, the server transfers it to the client. This transfer is called downloading.

   # 6.2 BOOTP Management Commands

   Table 6-1 summarizes the BOOTP management commands.

   Table 6-1 BOOTP Management Commands
   Command | Function
   --- | ---
   CONVERT /VMS BOOTP | Populates and existing BOOTP database with entries from a UNIX /etc/botptab file
   CREATE BOOTP | Creates an empty BOOTP database
   SET BOOTP | Adds or modifies client entries to the BOOTP database
   SHOW BOOTP | Displays information from the BOOTP database
   ENABLE SERVICE BOOTP | Interactively enables the BOOTP service
   DISABLE SERVICE BOOTP | Interactively disables the BOOTP service
   SET CONFIGURATION ENABLE SERVICE BOOTP | Sets the configuration database to enable BOOTP upon UCX startup
   SET CONFIGURATION DISABLE SERVICE BOOTP | Sets the configuration database to disable BOOTP upon UCX startup
   SET SERVICE BOOTP | Configures the service in the services database
   SHOW SERVICE BOOTP | Displays BOOTP information stored in the services database

   # 6.3 BOOTP and TFTP Logical Names

   Table 6-2 lists the logical names you can use to manage the BOOTP software.

   Table 6-2 BOOTP and TFTP Logical Names
   Name | Function
   --- | ---
   UCX$BOOTP | Points to the location of the BOOTP database file.
   UCX$TFTP_ROOT | Defines a concealed device. Points to the TFTP data storage tree, for example, SYS$SYSDEVICE:[UCX$TFTP_ROOT.].

   # 6.4 BOOTP and TFTP Planning and Preconfiguration Tasks

   When planning BOOTP, you need to make decisions about the network configuration and the local BOOTP service.

   ## 6.4.1 Network Configuration Decisions

   Before you start to set up BOOTP, answer the following questions:

   - What clients will access the BOOTP server? For each client, obtain:
     - System image and location from where it can be copied
     - Additional information it might request
     - Hardware address (used as a lookup key)
     - IP address
   - What hosts in your network will run the BOOTP server?
   - Will gateways be used for downloading? Gateways let you specify a specific path for the data transfer.
   - Do you want to limit client access to specific server directories?

   ## 6.4.2 BOOTP Service Decisions

   Before you start to configure BOOTP and TFTP consider the following:

   - Default priority for the UCX$BOOTP server account in the user authorization file (UAF)
     For optimal performance, set the default priority level for the UCX$BOOTP user account.
     In a large or active subnetwork, clients might generate several broadcast requests per minute. The server continues to process all incoming requests, even those for which it lacks information in its database.
     In most cases, all this processing does not create system performance problems. However, it does use, perhaps unnecessarily, system resources. A different network configuration might avoid wasted system overhead.
   - Segmented subnetworks
     To reduce large volumes of BOOTP request traffic to a specific server, segment very large subnetworks with filtering bridges.
     If you configure multiple servers, each server competes to provide the requested configuration information. For efficient server usage, partition their databases with a subset of the overall client population designated to each server.
   - Separate directory for each client
     To avoid writing over the same file name with configuration information from multiple clients, create a separate directory in the UCXTFTP_ROOT: directory tree for each client.
     Some BOOTP clients such as routers and terminal servers have an upline dump function that can store configuration options on the BOOTP and TFTP server host. In a network with two or more of these clients, they can use the same file name to store the configuration information with TFTP.
   - Security needs
     Identify your system's security needs (see Section 6.5).

   # 6.5 BOOTP Security

   For security purposes, the server runs as an unprivileged image that can access only the directories and files for which it has read access.

   Previous | Next | Contents