# Compaq TCP/IP Services for OpenVMS
Management

Previous | Contents | Index

## 6.3.2 How the Metric Server Calculates Load

The metric server calculates the current load on a DNS cluster host by using the following equation:

             rating = availablity + workload - penalty

In the equation, the variables are calculated by:

- Availability
  Availability is calculated using the IJOBLIM system parameters and the SDA global reference variable IJOBCNT in the following equation:

          availablity = (20*(IJOBLIM-IJOBCNT))/IJOBLIM

- Workload
  One consideration in the work load calculation is the system manager's estimate of the host's relative CPU power specified by the system logical TCPIP$METRIC_CPU_RATING.
  To set a CPU power value, use the DCL command DEFINE to define the system logical name TCPIP$METRIC_CPU_RATING with a value. The CPU rating value can range from 1 (the lowest CPU power) to 100 (the highest CPU power). If a value is specified, the value is used instead of the term (min(235,IJOBLIM) in the following equation.

          workload = (min(235,IJOBLIM)*100)/(100+load_average)

  When you set the logical value to 0, or if you do not define TCPIP$METRIC_CPU_RATING, the metric server uses the value of the system parameter IJOBLIM to calculate work load.
  `load_average` is an average of the current CPU load taken every second. It is calculated by using 97.9% of the previous CPU load and 2.1% of the current CPU load value.
- Penalty
  The metric server uses the FREEGOAL system parameter and the SDA global reference variable FREECNT to calculate an available memory penalty.

          penalty = 40*((FREEGOAL+2048-FREECNT)/(FREEGOAL+2048))

  The value of `penalty` is subtracted from the rating only if the value is positive. If the value of FREECNT is high enough, the value of `penalty` is not applied.

# 6.4 Load Broker Startup and Shutdown

The load broker can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

- SYS$STARTUP:TCPIP$LBROKER_STARTUP.COM allows you to start up the load broker service.
- SYS$STARTUP:TCPIP$LBROKER_SHUTDOWN.COM allows you to shut down the load broker service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

- SYS$STARTUP:TCPIP$LBROKER_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the load broker is started.
- SYS$STARTUP:TCPIP$LBROKER_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the load broker is shut down.

# 6.5 Configuring the Load Broker

To configure the load broker, edit the file TCPIP$LBROKER_CONF.TEMPLATE located in SYS$SYSDEVICE:[TCPIP$LD_BKR], then rename the file to TCPIP$LBROKER.CONF.

After making changes to TCPIP$LBROKER.CONF, restart the load broker by running TCPIP$CONFIG, or by using the shutdown and startup procedures.

The load broker configuration file can contain one or more DNS cluster statements in the following format:

    cluster "clustername.domain.com"
    {

     [dns-ttl nn;]
     [dns-refresh nn;]
     masters {ip_address};
     [polling-interval nn;]
     [max-members nn;]
     members {ip_address};
     failover {ip_address};
    };

Table 6-1 describes the valid cluster statements.

Table 6-1 Valid Cluster Statements
Statement | Description
--- | ---
`members` | Specifies the IP address for each DNS cluster member.
`failover` | Specifies the address of the host to use if all other members are down.
`masters` | Specifies the IP addresses of authoritative name servers.
`dns-ttl` | Specifies the time to live for a given record. The value you provide governs how long the record is to be cached by other name servers. If some intermediate name servers cache A resource records for a given DNS cluster name, they cache it for the period specified by `dns-ttl` for the resource record. The default value is 45 seconds.
`dns-refresh` | Specifies how often the DNS information for a given DNS cluster name is refreshed. The default is 30 seconds. The value of this field should be set relative to to the value of `polling-interval` . The `dns-refresh` value should be smaller than the `polling-interval` value. It is unproductive to refresh more often then you poll.
`polling-interval` | Specifies the length of time between polls to cluster members. The default is 30 seconds.
`max-members` | Specifies the maximum number of IP addresses to be returned to the name server in each dynamic update. For effective load balancing, this number should be between one-third and one-half the number of participating DNS cluster members.

The following sample is a configuration of the load broker that load balances the DNS cluster named WWW.TCPIP.ERN.SEA.COM.

    cluster "www.tcpip.ern.sea.com"
    {
     dns-ttl   45;
     dns-refresh  30;
     masters {
      9.20.208.53;
     };
     polling-interval  9;
     max-members   3;
     members {
      9.20.208.100;
      9.20.208.53;
      9.20.208.54;
      9.20.208.80;
      9.20.208.129;
      9.20.208.130;
     };
     failover 16.20.208.200;
    };

To retain your UCX Version 4.x DNS cluster load-balancing configuration:

1. Enter the CONVERT/CONFIGURATION BIND/CLUSTER command, as shown in the following example:

       TCPIP> CONVERT/CONFIGURATION BIND -
       _TCPIP> /CLUSTER=SYS$SYSDEVICE:[TCPIP$LD_BKR]TCPIP$LBROKER.CONF

   The output from this command is a TCPIP$LBROKER.CONF file containing your basic configuration.
2. Edit the TCPIP$LBROKER.CONF file to produce a complete configuration file.

## 6.5.1 Enabling the Load Broker

To enable DNS cluster load balancing, complete the following tasks:

1. Ensure that all hosts in the DNS cluster are running TCP/IP Services.
2. Configure the load broker (see Section 6.5).
3. Configure the BIND name server that is authoritative for the DNS cluster to allow dynamic updates from the host on which the load broker is running. For how to configure dynamic updates, see Section 5.3.6.
4. Ensure TCP/IP connectivity between the DNS cluster members and the load broker.
5. Enable the metric server on each member of the DNS cluster:
   1. Run the following command procedure:

          $ @SYS$MANAGER:TCPIP$CONFIG

   2. On the TCPIP$CONFIG Server Components Configuration menu, select option 8:

          8 -- METRIC.

   3. On the Metric configuration display, select option 2:

          2 -- Start service on this node.

Review the following guidelines:

- DNS cluster hosts and clients are not required to be on the same bridged LAN.
- The number of DNS cluster member hosts is limited to 32.
- A BIND name server can also be a DNS cluster member host.
- The authoritative name server can run any BIND name server that supports BIND 8.1.1 or later or that supports dynamic updates.

## 6.5.2 Load Broker Logical Names

Table 6-2 describes the load broker's logical names. Define these logical names with the /SYSTEM qualifier, and restart the load broker server to make the changes take effect.

Table 6-2 Load Broker Logical Names
Logical Name | Description
--- | ---
TCPIP$LBROKER_LOG_LEVEL value | Turns on diagnostics and writes them to the TCPIP$LBROKER_RUN.LOG located in SYS$SYSDEVICE:[TCPIP$LD_BKR]. Valid values are 1 and 2 (2 provides more detailed diagnostics).

## 6.5.3 Metric Server Logical Names

Table 6-3 describes the metric server's logical names. Define these logical names with the /SYSTEM qualifier. The metric server detects the change and dynamically updates the current enviroment.

Table 6-3 Metric Server Logical Names
Logical Name | Description
--- | ---
TCPIP$METRIC_CPU_RATING value | Sets a bias value that represents your estimate of the relative CPU power. Valid values range from 1 (lowest CPU power) to 100 (highest CPU power). Use a value of 0 (zero) to specify the default (The value of the system parameter IJOBLIM is used).
TCPIP$METRIC_COMPUTE_INTERVAL value | Specifies how often the metric server computes the rating. Valid value (in seconds) is a number from 1 to 300. The default is 10 seconds.
TCPIP$METRIC_LOG_LEVEL value | Turns on diagnostics logged to the file TCPIP$METRIC_RUN.LOG located in SYS$SPECIFIC:[TCPIP$METRIC]. Valid values are 1 or 2 (2 provides more detailed diagnostics).

# 6.6 Metric Server Startup and Shutdown

The metric server starts up automatically at system startup time if the service was previously enabled and can be shut down and started independently.

The following files are provided:

- SYS$STARTUP:TCPIP$METRIC_STARTUP.COM allows you to start up the metric service.
- SYS$STARTUP:TCPIP$METRIC_SHUTDOWN.COM allows you to shut down the metric service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

- SYS$STARTUP:TCPIP$METRIC_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the metric service is started.
- SYS$STARTUP:TCPIP$METRIC_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the metric service is shut down.

# 6.7 Solving Load Broker Problems

TCP/IP Services provides the following tools to assist in solving load broker problems:

- The Metric View utility, to display metric information regarding DNS cluster members.
- Diagnostic log files.

## 6.7.1 Metric View Utility

Two images in the TCP/IP Services software distribution kit perform the metric functions:

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

The Metric View utility, SYS$COMMON:[SYSEXE]TCPIP$METRICVIEW.EXE, displays the metric rating of the member hosts in the TCP/IP DNS cluster.

To run Metric View, enter the following command:

    $ RUN SYS$SYSTEM: TCPIP$METRICVIEW
    Host                                                    Rating
    ----                                                    ------
    10.10.2.11      rufus.lkg.dec.com                         47
    10.10.2.255     peach.lkg.dec.com                         51

## 6.7.2 Viewing Diagnostic Messages

If you define the logical TCPIP$METRIC_LOG_LEVEL, the METRIC server writes diagnostic messages to the TCPIP$METRIC_RUN.LOG file. If you are experiencing problems with the metric server, define TCPIP$METRIC_LOG_LEVEL and after a period of operation, review the messages in the TCPIP$METRIC_RUN.LOG file for an indication of what the problem could be. See Section 6.5.3 for a description of the logical.

# Part 3
Configuring Services

Part 3 describes how to set up and manage the Dynamic Host Configuration Protocol (DHCP), the Bootstrap Protocol (BOOTP), the Trivial File Transport Protocol (TFTP), the Portmapper service, the Network Time Protocol (NTP), and the Simple Network Management Protocol (SNMP). The chapters in this part include the following:

- Chapter 7, Configuring the DHCP Server, describes how to configure the DHCP server so you can centralize the configuration and maintenance of the IP address space.
- Chapter 8, Configuring the DHCP Client, describes how to set up the system as a DHCP client.
- Chapter 9, Configuring BOOTP, describes how to configure the BOOTP server so your host can answer bootstrap requests from diskless workstations and other network devices.
- Chapter 10, Configuring TFTP, describes how to configure the TFTP server to handle file transfers from diskless clients and remote systems.
- Chapter 11, describes how to configure the portmapper service, a service that registers server programs written using RPCs (remote procedure calls). You must run the portmapper service if you intend to run NFS or any customer-developed RPC programs.
- Chapter 12, Configuring and Managing NTP, describes how to configure and manage the NTP (Network Time Protocol), allowing your host to synchronize its time with that of other internet hosts also running NTP.
- Chapter 13, Configuring SNMP, describes how to configure your host so it can answer SNMP (Simple Network Management Protocol) requests from remote SNMP management stations.

# Chapter 7
Configuring the DHCP Server

Dynamic Host Configuration Protocol (DHCP), a superset of the Bootstrap Protocol (BOOTP), provides a centralized approach to the configuration and maintenance of IP address space. It allows the system manager to configure various clients on a network from a single location.

DHCP allocates temporary or permanent IP addresses from an address pool to client hosts on the network. DHCP can also configure client parameters such as default gateway parameters, domain name server parameters, and subnet masks for each host running a DHCP client.

This chapter reviews key DHCP and BOOTP concepts and also describes:

- DHCP server components ( Section 7.2)
- DHCP server startup and shutdown( Section 7.3)
- Configuring DHCP server ( Section 7.4)
- Using DHCP GUI to configure DHCP ( Section 7.5)
- Configuring DHCP/BOOTP IP addressing ( Section 7.6)
- Configuring DHCP manually ( Section 7.7)
- Supporting utilities ( Section 7.8)
- Solving DHCP server problems ( Section 7.9)

# 7.1 Key Concepts

With DHCP, system managers can centralize TCP/IP network configurations and management tasks involved with network connections. DHCP makes network administration easier by allowing:

- Consistent application of network parameters, such as subnet masks and default routers, to all hosts on a network
- Support for both DHCP and BOOTP clients
- Static (permanent) mapping of hardware addresses to IP addresses
- Dynamic (temporary) mapping of hardware addresses to IP addresses, where the client leases the IP address for a defined length of time

In addition, the TCP/IP Services implementation of DHCP includes support for DHCP server failover in a OpenVMS Cluster environment.

The DHCP protocol is a superset of BOOTP. In addition to the BOOTP functionality, DHCP offers robust configuration services, including IP addresses, subnet masks, and default gateways.

Based on the BOOTP functionality, DHCP is built on the client/server model:

- The DHCP server is a host that provides initialization parameters.
- The DHCP client is a host that requests initialization parameters from a DHCP server. A router cannot be a DHCP client.

## 7.1.1 How DHCP Operates

DHCP consists of two components:

- A mechanism for allocating network addresses to clients
- A set of rules for delivering client-specific configuration parameters from a DHCP server to a client

DHCP operates as follows:

- When a DHCP client boots, it broadcasts a DHCP request, asking that any DHCP server on the network provide it with an IP address and configuration parameters.
- A DHCP server on the network authorized to configure this client sends the client a reply that offers an IP address.
- When the client receives the offer, it can accept it or wait for other offers from other servers on the network.
- Once the client accepts an offer, it sends an acceptance message to the server.
- When the server receives the acceptance message, it sends an acknowledgment with the offered IP address and any other configuration parameters that the client requested. (The server only responds to specific client requests; it does not impose any parameters on the client.)
- If the dynamic address allocation method is used, the IP address offered to the client has a specific lease time that determines how long the IP address is valid.

During the lifetime of the lease, the client repeatedly asks the server to renew. If the client chooses not to renew, the lease expires.

Once the lease expires, the IP address can be recycled and given to another client. When the client reboots, it can be given the old address if available or assigned a new address.

For more information about how DHCP operates, see RFC 2131 and RFC 1534.

## 7.1.2 How DHCP Allocates IP Addresses

With TCP/IP Services, DHCP uses the dynamic and static IP address-mapping methods outlined in Table 7-1 to service DHCP and BOOTP-only client requests.

Table 7-1 DHCP IP Address Allocation Methods
Method | Applicable Client | Description
--- | --- | ---
Dynamic | DHCP and BOOTP | The DHCP server assigns an IP address from an address pool to a client for a specified amount of time (or until the client explicitly relinquishes the address). Addresses no longer needed by clients can be reused. Use dynamic allocation when: Clients plan to be connected to the network only temporarily. You have a limited pool of IP addresses that must be shared among clients that do not need permanent IP addresses. IP addresses are scarce, and you need to reclaim retired addresses so you can assign them the new clients being permanently connected to the network. For BOOTP clients, DHCP assigns dynamic IP addresses from the address pool and stores the addresses in the lease database by assigning each lease a time of infinity.
Static | DHCP and BOOTP | The system manager manually assigns (in the DHCPCAP. file) an IP address to a client and uses DHCP to pass the assigned address to the client. Use static allocation in an error-prone environment where it is desirable to manage IP address assignment outside of the DHCP functionality.
Finite | BOOTP-only | The DHCP server assigns an IP address from the pool to the BOOTP client and defines a lease time based on certain parameters you define in the SERVER.PCY file. When the lease expires, the DHCP server pings the IP address. If the server receives a reply, it extends the lease and does not offer the address to a new client. If not, the address is free and can be assigned to a new client.

Section 7.5 explains how to configure the different types of addressing for clients on your network.

The typical network uses a combination of static and dynamic DHCP addressing. As the local system manager or network administrator, you can apply any of the IP addressing methods as appropriate for your specific policies and environment.

## 7.1.3 Relationship Between DHCP and BOOTP

From the client's perspective, DHCP is an extension of the BOOTP functionality. DHCP allows existing BOOTP clients to operate with DHCP servers without having to change the client's initialization software.

Based on the format of BOOTP messages, the DHCP message format does the following:

- Captures the BOOTP relay agents and eliminates the need to have a DHCP server on each physical network segment.
- Allows existing BOOTP clients to operate with DHCP servers.
  Messages that include a DHCP message-type option are assumed to have been sent by a DHCP client. Messages without the DHCP message-type option are assumed to have been sent by a BOOTP client.

However, DHCP improves the BOOTP-only functionality in the following ways:

- DHCP allows the serial reassignment of network addresses to different clients by assigning a network address for a finite lease period.
- DHCP allows clients to acquire all of the IP configuration parameters they need to operate.

Previous | Next | Contents | Index