| Previous | Contents | Index |
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:
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:
Ten programs comprise the DHCP server component. Table 7-2 describes the programs.
| 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. |
| SERVER.EXE | 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. |
DHCP uses the configuration files described in Table 7-3 to control the behavior of the DHCP server and its service to DHCP clients.
| 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.
7.2.2.1 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 |
|---|
$ TYPE PINE$DKB0:[DHCP_CONFIG]SERVER.PCY
# server.pcy: server side policy file.
#
# $Id: server.pcy,v 1.25 1997/02/24 06:22:45 robs Exp $
#
# DESCRIPTION
# 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_service_updateable
# 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".
assign_name_by_hwaddr
accept_client_name
# 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
#ignore_name_owner
# Bootp.
# Remove this line if the server is not to support old-style Bootp
support_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.
#bootp_addr_from_pool
# 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.
auto_reread
# 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.
#check_bootp_client_net
# 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.
#ping_bootp_clients
# 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.
#reply_to_relay_on_local_net
# 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.
send_options_in_offer
# 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.
auto_release
# 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.
auto_sync_dbs
dns_tracks_dhcp_lease
# registered_clients_only
|
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 |
|---|
$ TYPE PINE$DKB0:[DHCP_CONFIG]DHCPCAP.
# dhcpcap: database for dhcp server
#
# $Id: dhcpcap,v 1.29 1996/02/08 19:20:14 hyung Exp $
#
# 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:
term_server:\
:ht=1:ha=08002ba22049:\
:ip=10.10.2.120:\
:bf=MNENG1:\
:bs=1159:\
:dn=compaq.com:\
:ds=10.10.2.14:\
:hd=sys$sysdevice[tcpip$bootp]:\
:sm=255.255.255.0:\
:td=tcpip$tftp_root:\
:sn=timber.compaq.com:
subnet_2:\
:nw=10.10.2.0:\
:gw=10.10.2.66:\
:ba=10.10.2.255:\
:lt=1200:t1=600:t2=1050:
subnet_4:\
:nw=10.10.4.0:\
:ba=10.10.4.255:\
:lt=1200:t1=600:t2=1050:
|
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 7-3 shows the contents of the NETS. file.
| Example 7-3 Sample NETS. File |
|---|
$ TYPE PINE$DKB0:[DHCP_CONFIG]NETS. # nets: pool of addresses available for allocation by specific join servers. # # $Id: nets,v 1.11 1996/01/15 17:50:00 hyung Exp $ # # DESCRIPTION # 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 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 # 10.10.2.0 0.0.0.0 10.10.2.100-10.10.2.110 10.10.4.0 0.0.0.0 10.10.4.100-10.10.4.110 |
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 |
|---|
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:
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 |
|---|
$ TYPE PINE$DKB0:[DHCP_CONFIG]NETMASKS. # 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 10.10.2.0 255.255.255.0 10.10.4.0 255.255.255.0 |
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 7-6 shows the contents of a typical NAMEPOOL. file.
| Example 7-6 Sample NAMEPOOL. File |
|---|
$ TYPE PINE$DKB0:[DHCP_CONFIG]NAMEPOOL.
# namepool: pool of names available for dynamic allocation.
#
# $Id: namepool,v 1.7 1996/01/15 17:53:11 hyung Exp $
#
# 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) 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 192.1.1.65 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 142.132.3.1 pc alpha bravo charlie delta echo engr.acme.com dhcpserver EngrPC victor whiskey xray yankee zulu |
In this example:
| Previous | Next | Contents | Index |