| Previous | Contents | Index |
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:
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:
With DHCP, system managers can centralize TCP/IP network configurations and management tasks involved with network connections. DHCP makes network administration easier by allowing:
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:
DHCP consists of two components:
DHCP operates as follows:
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.
8.1.2 How DHCP Allocates IP Addresses
With TCP/IP Services, DHCP uses the dynamic and static IP address-mapping methods outlined in Table 8-1 to service DHCP and BOOTP-only client requests.
| 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:
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 8.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.
8.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:
However, DHCP improves the BOOTP-only functionality in the following ways:
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.
8.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 8-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 8.8.1. |
| DBMODIFY.EXE | Modifies lease database. See Section 8.8.2. |
| DBREGISTER.EXE | Registers known MAC addresses. See Section 8.8.3. |
| DBSHOW.EXE | Displays specified binary database. See Section 8.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 8.8.1. |
| SIGNAL.EXE | Implements UNIX style kill to allow sending signals to DHCP server. See Section 8.4.3. |
DHCP uses the configuration files described in Table 8-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.
8.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 8-1 shows the contents of the SERVER.PCY file.
| Example 8-1 Sample SERVER.PCY File |
|---|
#
# File name: SERVER.PCY
# Product: HP TCP/IP Services for OpenVMS
# Version: V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#
# 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
# publickey 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
# Registered clients. When this flags in on DHCP service will only be
# granted to clients which have been pre-registered in the JOIN database.
# To pre-register a client used jdbreg or xjdbreg. This feature is only
# available starting in release 2.3
#registered_clients_only
# 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
# This toggle is used to ignore the so-called client ID
# and instead always use the MAC address to identify
# the client. It is useful to turn this on if you are
# trying to migrate clients either from BOOTP or from
# a vendor stack which doesn't set the ID to one
# which does.
#use_macaddr_as_id
# Turn on if you want to support Microsoft's Proxy Remote Access Server
# (RAS). The RAS server generates a BOOTP packet with a MAC address
# of 16 octets. JOIN recognizes these packets and will ignore them
# (and complain about them in the log) unless this toggle is on.
# This option is not currently supported on OpenVMS.
#support_microsoft_ras
# Turn on if you are using Token Ring Source Routing
# Currently this is only supported on HPUX platforms.
#tr_source_routing
# Use canonical_name to override the default (which will
# normally be the value returned by "gethostname". This is
# primarily for multihomed hosts which have the
# canonical name corresponding to an interface which
# is ignored by JOIN (e.g. ATM interfaces).
# and for high-availability servers which have per-service
# IP addresses which differ from any "physical" ip host address
#canonical_name glenroy
# Expand the BOOTP reply packet to 548 bytes (BOOTP clients only).
# Normally joind replies with a packet of 300 octets (the legal minimum),
# or a size equal to the size of the packet received, whichever is
# the bigger. Setting this parameter on causes all replies to BOOTP
# clients to be 548 octets. (These sizes are exclusive of the UDP (8)
# IP (20, usually) and LINK LAYER (14 of 10MBPS ethernet) headers
#expand_bootp_packet
# Dynamically created name to IP mappings in the DNS are normally
# permanent. Toggle this parameter "on" to have the mappings
# in the DNS expire when the DHCP lease expires.
#dns_tracks_dhcp_lease
# If a DHCP client needs a bootfile, send the name of that file in the BOOTP
# 'file' field, not as a DHCP option (option 67). BOOTP clients *always*
# receive a bootfile name in the 'file' field, regardless of this option
#bootfile_not_sent_as_option
# Ignore the hardware type field. For client s which *don't* use DHCP
# client identifiers, this toggle tells the server to use the clients
# hardware address as its identifier, *BUT* to ignore the hadware
# type field. In the JOIN DB the identifier is stored with a type field
# of zero (which is also the type for those clients which are using
# client idetfifiers)
#ignore_hardware_type
# When "on" server ignores the value of the "broadcast bit" and always
# broadcasts reply, even when the client can receive a pseudo unicast
# reply. This was needed by some Cabletron "smart" bridges.
#force_broadcast_reply.
|
| Previous | Next | Contents | Index |