HP TCP/IP Services for OpenVMS

Previous Contents Index Client Configuration Parameter

The DHCPCAP. file describes the various configuration parameters for clients. This file is similar to the standard bootptab file used by most BOOTP servers. Each entry in the file can describe a single machine (per-node basis), all the machines within a subnet (per-subnet basis), or a group of machines (per-group basis).

Example 8-2 shows typical information found in the DHCPCAP. file. For information on how to modify the DHCPCAP. file, see Section 8.7.2.

Example 8-2 Sample DHCPCAP. File

# File name:      DHCPCAP. 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# This file is used by the server when running with the text 
# database. 
# Using the tc= capability to factor out identical data 
# from several entries. Multiple tc's permit as many 
# levels of indirection as desired. 
# Be careful about including backslashes where they're needed. 
# Strange things can happen otherwise. 
# The data which follows is for example only. You should delete 
# and add entries appropriate to configuration of your own 
# networks. 
# A global entry which everybody uses.. 
# :yd=alpha.beta.gamma.com:\
# :to=28800: 
# Next entries for each subnet. . . 
# :tc=.global:\
# :nw=\
# :gw=\
# :ba=\
# :lt=7200:t1=3600:t2=6300: 
# :tc=.global:\
# :nw=\
# :gw=\
# :ba=\
# :lt=1200:t1=600:t2=1050: 
# Individual entries... 
# An old-style BOOTP client with the ip address hard-wired. 
# This assumes that this BOOTP client will always be on 
# subnet 
# :ht=1:ha=0a0b0c0d0e0f:\
# :ip=\
# :bf=mybootfile:\
# :sa=\
# :tc=.global: 
# A DHCP client. The lease time here (1day) overrides that specified in the 
# network entries 
# :ht=1:ha=0a0b0c0d0e1f:\
# :lt=86400:\
# :tc=.global Network Addresses

The NETS. file describes the ranges of IP addresses available to the server for the clients. Both BOOTP and DHCP use this pool of addresses whenever dynamic IP assignment is needed.

Each entry in the file consists of three fields:

Example 8-3 shows the contents of the NETS. file.

Example 8-3 Sample NETS. File

# File name:      NETS. 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# This file instructs the server which nets and subnets it is to 
# administer and addresses which are available for dynamic allocation. 
# Each non-comment line in this file has up to three fields: 
#    Subnet IP address 
#    IP address or name of host "owning" the address range. 
#    The address range itself 
# If there are fewer than three fields then the subnet and owner 
# are implied by previous entries. The address range is specified 
# as one or two IP addresses. If two then they must be separated 
# by a dash "-", with no whitespace intervening. Multiple ranges 
# may be specified for any owner. The IP addresses are checked for 
# syntax, for uniqueness of ownership, and validity on the network 
# specified. If the owner of a range is multi-homed, then the 
# name used must be its canonical name (e.g. as echoed by hostname), 
# or, if specified by address, the address must correspond to 
# the canonical name as given in /etc/hosts 
# For OpenVMS with DHCP configured on multiple cluster nodes (ie. DHCP 
# cluster failover) enter in the "owning" DHCP server field 
# (field 2). 
# Examples: 
# DHCP cluster failover example: 

The entries in the NETS. file shown in Example 8-4 describe the IP ranges for two different networks, each with its own set of IP addresses.

Example 8-4 NETS Entries with IP Ranges for Two Networks 
                (1)  dhcpserver  (2)

In this example:

  1. This entry comprises two lines and describes three noncontiguous ranges of IP addresses for the network
  2. This entry describes a single range of addresses for the network Notice the use of an IP address in the first entry ( and the use of a host name ( dhcpserver ) in the second entry to describe the owner of the IP address ranges. Netmask Masks

If your network is subnetted in a format that is not consistent with the standard class A, B, or C netmask address, you must include the network addresses and netmasks in the NETMASKS. file during the initial DHCP server configuration. Make sure you edit the NETMASKS. file and include an entry for each network. Each entry in the file must include two fields: the network address and the netmask address. Example 8-5 show a sample NETMASKS. file.

Example 8-5 Sample NETMASKS. File

# File name:      NETMASKS. 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# Network masks. This file is only needed on those platforms 
# which don't provide a netmasks database, either as a text 
# file or as a map (NIS, NIS+, .. whatever). 
# This file should contain an entry for each network for which 
# the netmasks is other than the standard A,B or C mask. Each 
# entry has two fields: the network and the mask. The network 
# must be written with trailing zeros: e.g For net 192.1.1 
# you do not enter 
#     192.1.1 
# but 
# This file also supports variable subnetting: i.e. if each 
# subnetted net can in turn be subnetted with a variable 
# mask then the subnets can also appear on the LHS. Thus 
# Network  netmask NamePool

The NAMEPOOL. file specifies a collection of names available for dynamic assignment to DHCP clients. The server uses the names in this file only when the name is not provided another way. For example, the server might use this file when the client did not suggest a name and when there is no name associated with the IP address being offered to the client.

In addition to this pool of names, there is also a name prefix. Once the name pool is exhausted, the server generates names from the prefix by appending the number 1, 2, or 3, along with a trailing "d". After a name has been dynamically bound to a host, the server never uses the name again, even if that host subsequently acquires a new name.

Each entry in the file consists of four fields:

Example 8-6 shows the contents of a typical NAMEPOOL. file.

Example 8-6 Sample NAMEPOOL. File

# File name:      NAMEPOOL. 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# This file contains names to be allocated to new machines coming onto the 
# network. Each group of names is introduced by a single line containing 
# two or three fields: the # domain name to which the names apply, the 
# machine (name of address) authorised to dispense them, and (optionally) 
# a prefix which will be used to generate names automatically within that 
# domain. White space is used to separate these fields; there must be no 
# leading whitespace on these lines. 
# Following this are the names. These may be written one or many 
# to a line, but each line must begin with a blank or tab. 
# The character '#' introduces comments. The text following '#' 
# to the end of line will be ignored by the parsing program. 
# Blank lines and lines beginning with '#' are ignored. 
# In summary format is: 
# domain_name  server  generic_name 
#       hostname... 
# Example: 
# alpha.beta.gamma.com  coastal-areas 
# north-utsire south-utsire viking forties cromarty forth tyne dogger 

Example 8-7 shows a NAMEPOOL. file containing a name prefix.

Example 8-7 NAMEPOOL Entries Showing the Use of a Name Prefix

acme.com   pc      alpha bravo charlie delta echo 
engr.acme.com   dhcpserver    EngrPC  victor whiskey xray yankee zulu 

In this example: .DDNSKEYS

The .DDNSKEYS file describes each DNS domain and the DNS name server that is to receive Host/IP address update information when DHCP distributes an address to a DHCP client in the domain. The information in this file consists of the domain to be updated and the IP address of the DNS server to which DHCP sends the updates. A third field for secure dynamic updates is reserved for future use. TCP/IP Services does not support secure dynamic updates.

This file is required for DHCP to perform DNS dynamic updates.

The following example shows the contents of a typical .DDNSKEYS file:

# File name:      .DDNSKEYS 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# This file describes each DNS domain and the DNS name server to which to send 
# dynamic updates for that domain. The first field is the domain. The second is 
# the DNS server to receive updates for the domain. There is a third as yet 
# unsupported field for use with secure dynamic DNS updates. In most common use 
# there will be entries for forward and reverse translation. 
# This example defines the DNS server at IP address to receive 
# dynamic updates for the compaq.com domain (A records) and the 
# 10.10.in-addr.arpa domain (PTR records). 

8.2.3 Command Files

Table 8-4 describes the command files used by the DHCP server.

Table 8-4 DHCP Server Command Files
Command File Name Description
TCPIP$DHCP_SETUPCOMMANDS.COM Defines symbols to invoke DHCP utilities. It is located in the SYS$MANAGER: directory.
TCPIP$DHCP_STARTUP.COM DCL commands to start the DHCP server.
TCPIP$DHCP_CLUSTER_STARTUP.COM DCL commands to start the DHCP server in a cluster failover configuration.
TCPIP$DHCP_SHUTDOWN.COM DCL commands to stop the DHCP server.
TCPIP$DHCP_CLUSTER_SHUTDOWN.COM DCL commands to stop DHCP server in a cluster failover configuration.
TCPIP$DHCP_RUN.COM Command procedure for starting DHCP server during the startup of DHCP server.
TCPIP$DHCP_SYSTARTUP.COM Site-specific definitions and parameters to be invoked when DHCP starts.
TCPIP$DHCP_SYSHUTDOWN.COM Site-specific definitions and parameters to be invoked when DHCP is shut down.

8.2.4 Logical Names

By establishing logical names, you can modify the following server characteristics:

Table 8-5 lists the DHCP logical names and describes their function.

Table 8-5 DHCP Server Logical Names
Logical Name Description
TCPIP$DHCP_CONFIG directory If defined, places the following DHCP files (during TCPIP$CONFIG) in the directory you specify:
  • DHCP configuration files in ASCII format (for example, SERVER.PCY)
  • DHCP database files in binary format (for example, DBA.BTR)
  • Binary database lock files (for example, RWLOCKDBA)
  • Temporary files created by TCPIP$CONFIG during the BOOTP-to-DHCP rollover
  • The server's process identification file (JOIN.PID)

Setting this logical name is useful when you want to move the file location off the system disk or when you want to set up a DHCP cluster failover environment (see Section 8.4.5). The logical name must be defined before running TCPIP$CONFIG.

If not defined, the preceding DHCP-related files are placed in SYS$SYSDEVICE:[TCPIP$DHCP] during the TCPIP$CONFIG procedure.

TCPIP$DHCP_DEBUG value Logs full diagnostics. Valid numeric values are 1 to 6. If you define this logical, the value of TCPIP$DHCP_LOG_LEVEL is ignored.
TCPIP$DHCP_LOG name Defines the name of the DHCP server log file. The default is TCPIP$DHCP_RUN.LOG.

If defined, each time the auxiliary server starts a DHCP server process, two log files are created: the one you define with TCPIP$DHCP_LOG name and the default TCPIP$DHCP_RUN.LOG.

TCPIP$DHCP_LOG_LEVEL value Writes the specified level of diagnostic information to the log file. Ignored if TCPIP$DHCP_DEBUG is defined.

Valid numeric values are:
0 Logs only error messages. This is the default.
1 Log warning messages.
2 Log all messages.

You define system wide TCPIP$DHCP logical names in the SYS$STARTUP:TCPIP$DHCP_SYSTARTUP.COM file. After making changes to the file, enter the following commands:


Alternatively, you can follow these steps:

  1. Manually define the system logical names.
  2. Use DHCPSIGHUP to signal the DHCP server.

8.2.5 Log Files

The DHCP server creates a log file named TCPIP$DHCP_RUN.LOG in the directory SYS$SYSDEVICE:[TCPIP$DHCP].

8.3 DHCP Server Startup and Shutdown

The DHCP server can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

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

8.3.1 Stopping the DHCP Server Process

If you specified automatic startup during the TCP/IP Services configuration procedure (TCPIP$CONFIG), the DHCP server process starts automatically when the DHCP service is started (TCPIP$DHCP_STARTUP.COM).

If you want to stop the DHCP server process, enter the following utility command as defined in SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM:


Be aware that a new DHCP server process starts automatically as soon as the old process exits unless you disable the DHCP service before entering a DHCPSIGTERM command. As an alternative method, you can shut down DHCP by executing the following command:


Because the DHCP server has several binary databases open (updates to which might not have been flushed to the disk), do not stop a running DHCP process using the DCL command STOP/ID=entry_number. Instead, stop the DHCP process by entering the DHCPSIGTERM command.

8.4 Configuring the DHCP Server

To configure the DHCP server, perform the following tasks:
Task Described in...
Enable DHCP on your system and set up DHCP files and databases. Section 8.4.1
Set up DNS/BIND. Section 8.4.2
Set up the cluster failover environment. Section 8.4.5
Stop the DHCP process. Section 8.3.1
Shut down and start up the DHCP process. Section 8.3
Configure client information (use the DHCP GUI or make changes manually). Section 8.5 or Section 8.7, respectively
Set up the NETMASKS. file, if appropriate. Section
Define IP addressing. Section 8.6

8.4.1 Enabling the DHCP Server

To enable DHCP initially, run the TCPIP$CONFIG procedure by entering the following command and then choose DHCP from the Server Components menu:


The configuration procedure asks if you want to convert existing BOOTP entries to DHCP database:

Do you want to rollover old-style BOOTP entries into the DHCP 
database? [Y] 

Previous Next Contents Index