HP OpenVMS Systems Documentation

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.

#
# File name:      DHCPCAP.
# Product:        HP TCP/IP Services for OpenVMS
# Version:        V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#

# DESCRIPTION:
#
# 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..

#.global:\
# :yd=alpha.beta.gamma.com:\
# :to=28800:

# Next entries for each subnet. . .

#subnet32:\
# :tc=.global:\
# :nw=192.1.1.32:\
# :gw=192.1.1.33:\
# :ba=192.1.1.63:\
# :lt=7200:t1=3600:t2=6300:

#subnet64:\
# :tc=.global:\
# :nw=192.1.1.64:\
# :gw=192.1.1.65:\
# :ba=192.1.1.95:\
# :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 192.1.1.32
#.xterm:\#
# :ht=1:ha=0a0b0c0d0e0f:\
# :ip=192.1.1.36:\
# :bf=mybootfile:\
# :sa=192.1.1.33:\
# :tc=.global:

# A DHCP client. The lease time here (1day) overrides that specified in the
# network entries
#.xtermb:\
# :ht=1:ha=0a0b0c0d0e1f:\
# :lt=86400:\
# :tc=.global

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:

• The network number expressed as an IP address, for example, 142.132.3.0.
• The owner of this IP address range expressed as the IP address of the server host (142.132.3.1) or the host name ( dhcpserver in Example 8-4). If a DHCP cluster failover environment is configured (see Section 8.4.5), the IP address is defined as the null address 0.0.0.0 so that applicable cluster nodes can receive packets.
• A range of available addresses for dynamic allocation to hosts on the network.
  The range is expressed as a pair of IP addresses with a hyphen (-) between them, for example, 143.32.3.10-143.32.3.30. There must be no extra space separating the dash from the IP addresses. You can specify more than one range for each network; the ranges need not be contiguous.

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

#
# File name:      NETS.
# Product:        HP TCP/IP Services for OpenVMS
# Version:        V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#

# DESCRIPTION:
#
# 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 0.0.0.0 in the "owning" DHCP server field
# (field 2).
#

# Examples:
#192.1.1.32      192.1.1.34       192.1.1.35-192.1.1.43
#192.1.1.32      192.1.2.34       192.1.1.44-192.1.1.62
#192.1.1.64      192.1.2.34       192.1.1.66-192.1.1.94
#
# DHCP cluster failover example:
#192.1.1.64      0.0.0.0          192.1.1.66-192.1.1.94

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.

143.32.3.0  143.32.3.1 143.32.3.10-143.32.3.30  143.32.3.40-143.32.3.60
            143.32.3.75-143.32.3.100              (1)

143.32.5.0  dhcpserver  143.32.5.10-143.32.5.200  (2)

In this example:

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

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.

#
# File name:      NETMASKS.
# Product:        HP TCP/IP Services for OpenVMS
# Version:        V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#

# DESCRIPTION:
#
# 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
#
#     192.1.1.0
#
#
# 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
#
#     192.1.1.0      255.255.255.224
#     192.1.1.96     255.255.255.240
#
# Network  netmask

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:

• The domain to which the names apply.
• The owner of these names, expressed as either the IP address of the server host (142.132.3.1) or the host name ( dhcpserver ).
• An optional name prefix, used for generating names after the name pool is exhausted.
• A list of names in the pool.

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

#
# File name:      NAMEPOOL.
# Product:        HP TCP/IP Services for OpenVMS
# Version:        V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#

#
# DESCRIPTION:
#
# 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  192.1.1.65  coastal-areas
# north-utsire south-utsire viking forties cromarty forth tyne dogger

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

acme.com        142.132.3.1   pc      alpha bravo charlie delta echo

engr.acme.com   dhcpserver    EngrPC  victor whiskey xray yankee zulu

In this example:

• The first entry describes five names available to the acme.com domain with a name prefix of pc .
• The second entry describes five different names for the engr.acme.com domain with a name prefix of EngrPC . Notice the use of an IP address in the first entry (143.32.3.1) and the use of a host name ( dhcpserver ) in the second entry to describe the owner of the IP address ranges.

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.
#

# DESCRIPTION:
#
# 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 10.10.2.14 to receive
# dynamic updates for the compaq.com domain (A records) and the
# 10.10.in-addr.arpa domain (PTR records).
#
#hp.com   10.10.2.14
#10.10.in-addr.arpa 10.10.2.14

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

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

• The directory in which the DHCP configuration files and databases are placed during TCPIP$CONFIG
• Error logging and diagnostics

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

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:

$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM
$ @SYS$STARTUP:TCPIP$DHCP_STARTUP.COM

Alternatively, you can follow these steps:

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

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:

• SYS$STARTUP:TCPIP$DHCP_STARTUP.COM allows you to start up the DHCP service.
• SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM allows you to shut down the DHCP 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$DHCP_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when DHCP is started.
• SYS$STARTUP:TCPIP$DHCP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when DHCP is shut down.

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:

$ DHCPSIGTERM

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:

$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN

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 enable DHCP initially, run the TCPIP$CONFIG procedure by entering the following command and then choose DHCP from the Server Components menu:

$ SYS$STARTUP:@TCPIP$CONFIG

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]

• If you answer Yes, the TCPIP$DHCP_BOOTPTODHCP.COM procedure tries to locate the existing BOOTP database. Once it locates a file, the configuration procedure asks you to confirm its selection or make a new selection:

  Name of file to use for old-style BOOTP: SYS$SYSTEM:TCPIP$BOOTP.DAT Press return or enter new file name:

  
  The configuration procedure does the following to the file:
  • Converts any existing BOOTP information to the appropriate DHCP format in the new DHCPCAP. configuration file.
  • Sets up the DHCP server to support BOOTP clients.
  • Sets up permanent leases for existing BOOTP clients.
  
  During TCPIP$CONFIG, all DHCP-related files are placed in the SYS$SYSDEVICE:[TCPIP$DHCP] directory unless you define the system logical name TCPIP$DHCP_CONFIG (see Table 8-5).
• If you answer No, the new DHCP configuration file DHCPCAP. remains empty, and your BOOTP clients will not be served.
  TCPIP$CONFIG invokes the command procedure SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM, which defines the GUI Server Management Console and DHCP utilities as OpenVMS foreign commands.

  Important HP recommends calling the TCPIP$DHCP_SETUPCOMMANDS.COM procedure as part of the login process for all users who are authorized to manage the DHCP server.