HP OpenVMS Systems Documentation

Content starts here

Compaq TCP/IP Services for OpenVMS

Previous Contents Index

7.1.4 Client ID

With BOOTP, a client is identified by its unique media access control (MAC) address that is associated with the network adapter card.

DHCP uses a client identifier (ID) to uniquely identify the client and associate it with a lease: The client creates the client ID from one of the following types of addresses:

  • The MAC address.
  • A variation of the MAC address. For example, Windows 95 and Windows NT clients create the client ID by prepending the hardware type to the hardware address.

If the client does not include a client ID in the request, the server uses the client's MAC address.

7.2 DHCP Server Components

This section describes the software and system elements that comprise the DHCP server component, including:

  • Executable files
  • Configuration files
  • Command files
  • Logical Names
  • Log files

7.2.1 Executable Files

Ten programs comprise the DHCP server component. Table 7-2 describes the programs.

Table 7-2 DHCP Executable Files
Program Name Description
BPASCIITODBMOD.EXE Used in rollover of old-style UCX BOOTP entries to DHCP.
BPISAMTOASCII.EXE Used in rollover of old-style UCX BOOTP entries to DHCP.
DBDUMP.EXE Dumps lease database in single line ASCII format. See Section 7.8.1.
DBMODIFY.EXE Modifies lease database. See Section 7.8.2.
DBREGISTER.EXE Registers known MAC addresses. See Section 7.8.3.
DBSHOW.EXE Displays specified binary database. See Section 7.8.1.
GUI.EXE DHCP GUI. Used to manage DHCP server.
SHOWDBS.EXE Displays lease database in easy to read format. See Section 7.8.1.
SIGNAL.EXE Implements UNIX style kill to allow sending signals to DHCP server. See Section 7.4.3.

7.2.2 Configuration Files

DHCP uses the configuration files described in Table 7-3 to control the behavior of the DHCP server and its service to DHCP clients.

Table 7-3 DHCP Configuration Files
File Name Description
SERVER.PCY Describes the behavior of the server. For example, the policy file tells you whether BOOTP clients should be supported, the ping timeout value, and so on.

You may need to make modifications to this file to change the default settings. Some of the defaults include support for BOOTP clients and assigning names by IP addresses.

DHCPCAP. Defines the client configuration parameters.

This file is similar to the standard BOOTPTAB file used by most BOOTP servers. Each entry in the file can describe a single host, all the hosts within a subnet, or a group of hosts.

NETS. Defines the pool of IP addresses available to the DHCP server to assign to clients. Used for dynamic address assignments.
NETMASKS. Defines network masks if the network is subnetted. If you use subnetting on your network, you must enter the subnet mask into the NETMASKS. file for your network to operate correctly. This is an optional file. If your network uses standard class A, B, or C network addressing, you do not need to enter a mask into this file.
NAMEPOOL. Defines the names available for assignment to DHCP clients. The server uses the names only as a last resort (for example, when the client did not suggest a name and there is no name associated with the IP address offered to the client).
.DDNSKEYS Defines the domains that are to be sent DNS/BIND dynamic updates. The name of this file consists only of a file type of DDNSKEYS.

The DHCP configuration files (except for log files) are located in SYS$SYSDEVICE:[TCPIP$DHCP] or in the directory pointed to by the logical name TCPIP$DHCP_CONFIG. Log files are always located in the SYS$SYSDEVICE:[TCPIP$DHCP] directory.

Template copies of the DHCP configuration files are located in text library file SYS$LIBRARY:TCPIP$TEMPLATES.TLB. The template copies provide instructions on how to edit the text files manually. Server Policy

The SERVER.PCY file configures the behavior of the server. This policy file describes various aspects of the server; for example, what sort of name service to use, whether BOOTP should be supported, and the ping timeout value.

Use new lines to separate entries in the SERVER.PCY file from one another. The server ignores blank lines and comments (lines beginning with the pound (#) symbol). Each new policy option must begin and end on a separate line. A keyword introduces a policy option. A policy option can be Boolean or can take a value separated from the keyword by a space (but not by a new line).

If the SERVER.PCY file contains more than one specification for an option, only the value associated with the last specification takes effect; the server disregards earlier specifications.

Example 7-1 shows the contents of the SERVER.PCY file.

Example 7-1 Sample SERVER.PCY File

# server.pcy: server side policy file.
# $Id: server.pcy,v 1.25 1997/02/24 06:22:45 robs Exp $
# This is a template server.pcy file. A particular site may need to make
# modifications to this, especially to the name service and name allocation
# policies in force

# Default time-to-live for an address lease if not specified on a
# per host, per subnet or per class basis.

default_ttl 86400

# Time to live on provisional list

provisional_ttl 60

# Size of the internal array specifying the number of address
# blocks held on the free list. This number should not be too
# high, or the server will "forget" about all previous allocations
# of expired leases very quickly. It should not be too low or
# performance will suffer.

free_list_size 8

# Define type of name service. The name service is one of
# { dns, local, nis, nis+}.
# local means use text files on the local system (i.e. /etc/hosts).

# On OpenVMS leave this option as "dns".

name_service dns

# Specify whether the name service is dynamically updateable.
# NIS and NIS+ are dynamically updateable, but the system
# administrator may choose to disable this capability. In
# both cases the server must be in the same domain as the
# name server, and the JOIN server's key must be in the
# public database. NIS also requires the creation of
# a pseudo map, "join", and the installation of the file
# "updaters" in /var/yp on the name server. See manual
# for further details. This option can be enabled for DNS.
# The default is not to permit dynamic updating.


# Name policy
# The name may be choosen according to three possible policies:
#   assign_name_by_hwaddr:
#       A particular client (identified # by its hardware address)
#       always has the same name wherever possible. This option
#       may only be choosen if the name service is updateable.
#   assign_name_by_ipaddr:
#       The client gets a name from the IP address which was
#       assigned to it, as found in the name service. This
#       option is incompatible with assign_name_by_hwaddr.
#   accept_client_name:
#       This toggle is valid only when the policy is
#       assign_name_by_hwaddr. When "on" the server will use
#       the name suggested by the client and bind it to the
#       IP address delivered by the DHCP protocol. This is
#       true even if the client in question already has a name
#       in the server's DB which is not the name suggested.
#       The old name continues to be "owned" by the client
#       and may have a valid IP address bound to it.
#       When this toggle is "off" the server will return to
#       client a pre-existing name bound to the client identifier
#       or hardware address, regardless of the name the client
#       suggests to the server.
# If no name can be found by the application of one or more of
# these policies, the server will generate a name for the domain
# by using the name prefix in the "namepool" database.

# assign_name_by_ipaddr

# Note: The following two settings are most appropriate when you are using
# dynamic DNS updates. To set this up on the DHCP server side uncomment these
# lines and delete the line above with "assign_name_by_ipaddr".

# When the naming policy is assign_name_by_hwaddr the server will
# not allow a client to use a name which is "owned" by some other
# client. I.e. A name that is already bound to a different Client
# identifier or MAC address. When this toggle is on, this prohibition
# is lifted and the name will be re-assigned


# Bootp.
# Remove this line if the server is not to support old-style Bootp


#This boolean is only valid if Bootp clients are supported
#(support_bootp option is enabled). When present it permits
#the server to permanently assign an IP address from its
#free pool to a BOOTP client in the event that no permanent
#binding exists in dhcpcap. Normally the JOIN server can
#only service BOOTP clients for which such a binding pre-exists.


# Timeout value for ping in milliseconds. Before the server offers an
# address it pings (using ICMP echo) it: if a reply is received the
# server assumes that it is in use and makes another choice. "ping_timeout"
# is the number of milliseconds the server will wait for a reply.

ping_timeout 500

# Instructs the server to check whether or not the dhcpcap file appears to
# have changed each and every time a client configuration is required.
# If the file has changed (as indicated by its time stamp), the server
# will read and parse it anew.


# Before a BOOTP client is given a hard-wired IP address the server checks
# that the client is indeed connected to the logical IP network for which
# the address is valid. If not an error is logged and no response sent.
# In order for this to work properly the netmasks file must contain the
# network numbers and masks for any non-standard IP Class A, B or C
# configuration.


# Before an IP address is given to a BOOTP client the server first checks
# to see whether or not it is in use by sending an ICMP echo. If a reply
# is received an error is logged.  If the address was from the dynamic pool
# it will be marked un-available, and a new address selected from the pool.
# If the address was statically configured the server refuses to configure
# the client.


# The server will by default ignore any packets forwarded to it via a relay
# agent whose giaddr field shows it to be directly connected to the server -
# the server will, presumably, hear the clients broadcast directly. This
# option forces the server to reply regardless.


# The server will not send a complete configuration to a DHCP client unless
# this toggle is set. Resolving a client configuration can be time consuming
# and, in a multi-server environment, the client may select another server.


# Minimum packet size for DHCP requests.  By modifying this parameter,
# the DHCP server can be configured to work with some non-compliant
# DHCP clients that send DHCP requests smaller than the minimum required
# packet length.  By default, the minimum packet size is 300 bytes.

minimum_bootp_packet_size 300

# Set this true if you want to automatically delete leases when
# the client changes its net. I.e. if the server has leases for
# the client on several nets, and the client boots on a specific
# net, say X, the all the leases on all the nets except X, whether
# expired or not will be deleted.
# Note that some HW, notably SUN workstations, use a MAC address
# or client identifier which is the same regardless of the
# interface being configured. Therefore, two interfaces of a client
# of this tupe may appear to the server to be a single client
# which has changed network. You would probably not want to
# auto delete leases in this case.


# Finite Bootp lease support. When this parameter is non-zero it
# instructs the server to grant FINITE leases to BOOTP clients.
# BOOTP clients don't know this, so before the server can re-use
# these leases it must ping the IP address. If a reply is heard
# the server automatically extends the lease by this time interval (secs).
# Note that the *original* lease conferred on a BOOTP client is
# determined by the dhcpcap file, which need not be the same as
# this extension. Also that this capability is only relevant to
# BOOTP clients which are dynamically addresses (bootp_addr_from_pool
# toggle on).

bp_auto_extension 0

# Set auto_sync_dbs to flush the server database to disk
# after each update. This is more reliable in the event
# of a failure, but slows the server down.

# registered_clients_only 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 7-2 shows typical information found in the DHCPCAP. file. For information on how to modify the DHCPCAP. file, see Section 7.7.2.

Example 7-2 Sample DHCPCAP. File

# dhcpcap: database for dhcp server
# $Id: dhcpcap,v 1.29 1996/02/08 19:20:14 hyung Exp $
# 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:


                                :lt=1200:t1=600:t2=1050: 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:

  • The network number expressed as an IP address, for example,
  • The owner of this IP address range expressed as the IP address of the server host ( or the host name ( dhcpserver in Example 7-4). If a DHCP cluster failover environment is configured (see Section 7.4.5), the IP address is defined as the null address 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, 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 7-3 shows the contents of the NETS. file.

Example 7-3 Sample NETS. File

# nets: pool of addresses available for allocation by specific join servers.
# $Id: nets,v 1.11 1996/01/15 17:50:00 hyung Exp $
# This file instructs the server which nets and subnets it is to administer
# and the 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 7-4 describe the IP ranges for two different networks, each with its own set of IP addresses.

Example 7-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 7-5 show a sample NETMASKS. file.

Example 7-5 Sample NETMASKS. File

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

  • The domain to which the names apply.
  • The owner of these names, expressed as either the IP address of the server host ( 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 7-6 shows the contents of a typical NAMEPOOL. file.

Example 7-6 Sample NAMEPOOL. File

# namepool: pool of names available for dynamic allocation.
# $Id: namepool,v 1.7 1996/01/15 17:53:11 hyung Exp $
# 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) authorized 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
#       [TAB]  hostname...
# Example:
# alpha.beta.gamma.com  coastal-areas
#       north-utsire south-utsire viking forties cromarty forth tyne dogger

compaq.com      timber  timber
        dhcp1   dhcp2   dhcp3   dhcp4
        dhcp5   dhcp6   dhcp7   dhcp8
        dhcp9   dhcp10

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

Example 7-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:

  • 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 ( and the use of a host name ( dhcpserver ) in the second entry to describe the owner of the IP address ranges.

Previous Next Contents Index