DHCP uses the following methods to assign a host name:

• By hardware address
  When you specify this method, DHCP uses the host name suggested by a client when the client sends out its initial boot request.
  This method requires that both the DHCP and BIND servers are capable of and configured for performing dynamic DNS updates.
  To configure host name assignment using this method, see Section 8.4.2.1.
• By IP address
  If you specify this method to assign host names, DHCP performs a BIND IP address lookup to obtain a host name associated with the IP address. If the lookup is successful, DHCP uses the host name returned by BIND. If the lookup fails, DHCP creates a name from the NAMEPOOL. file.
  This method requires that you manually assign an IP address to each host and add A and PTR records to your DNS/BIND database.
  To configure host name assignment using this method, see Section 8.4.2.2.

To configure DHCP to assign a host name dynamically, perform the following steps:

1. Change the SERVER.PCY file (either manually or with the DHCP GUI) to include the following statements:

   name_service_updateable
   assign_name_by_hwaddr
   accept_client_name
   dns_tracks_dhcp_lease

2. Configure a DNS/BIND server to accept dynamic updates from your DHCP server. If you are running the DHCP server on multiple nodes, configure the DNS/BIND server to accept dynamic updates from each of the nodes. Refer to Section 6.5.7 for a discussion on how to configure DNS/BIND to accept dynamic updates from DHCP.
3. Edit the DHCPCAP. file to add a domain name for all subnet entries for which DHCP will perform dynamic DNS updates. To use the DHCP GUI to add dynamic DNS updates for a domain, do the following:
   1. Start the DHCP GUI as described in Section 8.5
   2. Select the Subnets tab.
   3. Select DHCP parameters from the drop down list
   4. Add the domain name to the DNS Domain Name parameter.
4. Create a .DDNSKEYS file with an entries for the DNS/BIND server that is to receive dynamic updates. You will most likely want to create an entry for A and PTR records by defining a forward and reverse translation entry.
5. Create a NAMEPOOL. file to supply a pool of names to use for nodes on the particular network. DHCP uses this pool of names to generate a host name only when other methods are unsuccessful.

To configure DHCP to use host names defined in a DNS/BIND server database, perform the following steps:

• Change the SERVER.PCY file (either manually or with the DHCP GUI) to include the following statement:

  assign_name_by_ipaddr

  
  Exclude the following statements:

  accept_client_name
  dns_tracks_dhcp_lease
  name_service_updateable

  
  See Section 8.2.2.1.
• Edit the DNS/BIND forward translation (domain_name.DB) file to include an A record for each IP address in the range of IP addresses that your DHCP server may allocate. It is common practice to assign IP addresses and names systematically. For example, if IP address 10.10.2.100 obtains the name dhcp1.xyz.com , then IP address 10.10.2.101 obtains the name dhcp2.xyz.com (see Section 6.6.4.4).
• Edit the DNS/BIND reverse translation (address.DB) file to include a PTR record for each host name (see Section 6.6.4.3).

One of the DHCP utilities that is defined in TCPIP$DHCP_SETUPCOMMANDS.COM is the TCPIP$DHCP_SIGNAL utility, which provides interprocess signaling in a manner similar to the UNIX kill signal delivery utility. PRMMBX and SYSNAM privileges are required to run TCPIP$DHCP_SIGNAL.EXE.

The following table shows the commands available with the TCPIP$DHCP_SIGNAL utility:

Command	Description
DHCPSIGHUP	Causes the ASCII configuration files to be read again, flushes the binary databases and then translates the TCPIP$DHCP_DEBUG and TCPIP$DHCP_LOG_LEVEL logical names.
DHCPSIGTERM	Causes an orderly shutdown of DHCP.
DHCPSIGUSR1	Causes a dump of the ASCII configuration files, then flushes the binary databases.

8.4.4 Returning to the BOOTP-Only Configuration

You can return to a BOOTP-only configuration at any time. Further, you can use the previous TCPIP$BOOTP.DAT database file and the client entries it contains. If you deleted the TCPIP$BOOTP.DAT file, you can create a new one and populate it with entries (see Section 10.5).

To enable BOOTP after you have configured your host for DHCP, run TCPIP$CONFIG and enable the BOOTP component from the Server Components menu. Your existing DHCP files will remain for future use.

8.4.5 Setting Up a DHCP Cluster Failover Environment

You can set up an OpenVMS Cluster environment for DHCP server failover. In this environment, a standby system becomes the DHCP server if the active DHCP server process fails or is stopped, or the system on which it is running fails or shuts down.

With cluster failover, the DHCP server uses the OpenVMS lock manager during process initialization to acquire a system-level, exclusive-mode lock on a resource called TCPIP$DHCP_SERVER. The first server started on the cluster obtains the lock on TCPIP$DHCP_SERVER and becomes the active DHCP server. The other DHCP servers wait to obtain the lock and become the standby servers.

When the active DHCP server process exits for any reason, the lock on TCPIP$DHCP_SERVER is released and one of the standby processes acquires the lock and becomes the active server.

To configure the DHCP server failover environment, do the following:

1. If the DHCP server is running on one of your systems, manually disable it by entering the following command on the server system:

   $ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM

2. Create a directory for the DHCP configuration and binary database files that is visible to the DHCP cluster members. Specify TCPIP$DHCP as the directory's owner. For example:

   $ CREATE/DIRECTORY/OWNER=TCPIP$DHCP WORK1$:[DHCP_CONFIG]

3. If you have already been running DHCP server and want to start with the existing data files, then do the following:
   1. Copy the DHCP data files from the DHCP directory to TCPIP$DHCP_CONFIG:*.* by entering commands similar to the following:

      $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%% TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS TCPIP$DHCP_CONFIG:

   2. Delete the DHCP data files from the DHCP directory by renaming them to a temporary subdirectory. (You can delete the files after you are sure that the failover environment is set up correctly.) For example, enter the following commands:

      $ CREATE/DIR SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ PURGE SYS$SYSDEVICE:[TCPIP$DHCP] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%%;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]

4. On each cluster node that is to serve as a potential DHCP server, set up the TCPIP$DHCP_CONFIG logical name as follows:
   1. Define TCPIP$DHCP_CONFIG as a systemwide logical name. For example:

      $ DEFINE/SYSTEM TCPIP$DHCP_CONFIG WORK1$:[DHCP_CONFIG]

   2. Before you run the TCPIP$STARTUP.COM procedure, add the TCPIP$DHCP_CONFIG logical name definition to the TCPIP$DHCP_SYSTARTUP.COM file.
5. On each cluster node that you want to be a DHCP server, run TCPIP$CONFIG to enable the DHCP service (see Section 8.4.1).
   The TCPIP$CONFIG procedure creates the TCPIP$DHCP account and stores initial copies of the DHCP configuration data files in the directory pointed to by the logical name TCPIP$DHCP_CONFIG. If you choose to roll over your BOOTP database to DHCP, TCPIP$CONFIG creates your initial DHCP binary database files in the TCPIP$DHCP_CONFIG directory.
6. Make sure that the auto_sync_dbs parameter is set in the SERVER.PCY file.
   This parameter causes the DHCP server databases to be flushed after each update. You can set the parameter by editing the SERVER.PCY file or by setting the auto_sync_dbs parameter to True on the Server/Security tab in the DHCP GUI.
7. Ensure that the files in TCPIP$DHCP_CONFIG: and the directory itself are owned by TCPIP$DHCP and have owner-only protection (O:RWED). For example:

   $ DIRECTORY/SECURITY WORK1$:[DHCP_CONFIG] $ DIRECTORY/SECURITY WORK1$:[000000]DHCP_CONFIG.DIR

8. Edit the NETS. file and set the ownership of any existing IP address range to 0.0.0.0.
   With the DHCP cluster failover configured, you need to indicate that an address range is owned by other hosts. Therefore, you specify the null IP address of 0.0.0.0 in the second field of the NETS. file in each IP address range to be shared among the DHCP servers. For example, the following entry in the NETS. file is owned by IP address 17.18.208.100:

   17.18.0.0 17.18.208.100 17.18.208.10-17.18.208.50

   
   You would change the entry to the following:

   17.18.0.0 0.0.0.0 17.18.208.10-17.18.208.50

   
   If you prefer to use the DHCP GUI to configure the null address, choose the IP Ranges parameter on the Server/Security tab and set the parameter to True.

9. Shut down DHCP on each cluster member where DHCP is running by using the TCPIP$DHCP_CLUSTER_SHUTDOWN command procedure. When the command procedure is finished, restart DHCP on the cluster by using TCPIP$DHCP_CLUSTER_STARTUP.

TCP/IP Services provides three methods for configuring server and client parameters:

• An easy-to-use DHCP graphical user interface (GUI) to do the following:
  • Configure dynamic and static IP addressing for all clients. See Section 8.6.
  • Configure the client information appropriate for your client base. See Section 8.5.
  • Set DHCP parameters to customize the DHCP server. See Section 10.4.3.
• Manually editing the DHCP configuration files and then signaling the DHCP server to read the files. See Section 8.7.
• Using the DHCPDBMOD utility. See Section 8.8.2.

You can modify the default DHCP server settings and define additional characteristics by performing the following tasks:

Task	Described in...
Define server and security parameters.	Section 8.5.2
Define subnet parameters.	Section 8.5.3.1
Define node parameters.	Section 8.5.3.2
Define group parameters.	Section 8.5.3.3

8.5.1 General Information

• You need the following system privileges:

  BYPASS
  SYSNAM
  PRMMBX

• If you have not already done so, execute the TCPIP$DHCP_SETUPCOMMANDS.COM command procedure to establish DHCP foreign commands .
• Invoke the GUI by entering the following utility program command:

  $ DHCPGUI

The system displays the configuration window with four tabs across the top of the window. The tabs allow you to configure the following sets of DHCP parameters:

Tab	Function
Server/Security	Defines the server configuration (see Section 8.5.2). You can set your IP address ranges, general server parameters, or view currently leased IP addresses and their lease time.
Subnets	Assigns client configurations for entire subnets.
Nodes	Adds and customizes specific machines on your network, usually for BOOTP clients.
Groups	Defines a group of settings for predefined collections of machines.

Choose a tab for the category of parameters you want to configure. The window for each tab has three columns:

• The left column lists the items that are configured for that category. The list always contains a [New Record] item to configure another machine. Choose an item from this list to enter or view its parameters.
• The middle column lists the available parameters for the selected item along with the current specification or setting. Choose a parameter to enter or change the specification or setting.
• The right column has fields for entering data. To add or change a parameter setting, select a parameter and enter the value for the parameter in the field to the right. You can enter values as:
  • Descriptive text, such as an IP address
  • Time in hours, minutes, and seconds
  • True or false statements
  
  When there is more than one value field, press Tab to move to the next field. To delete information in a field, select the text, then click Delete.

If you add or revise information in a field, you need to save the information using one of the following methods:

1. Choose Update from the File menu.
2. Choose Exit from the File menu, then choose Save and Exit. This updates the database when you exit the program.

For some subjects, you can add more than one record. To add a new record:

1. Choose [New Record] from the list on the left side of the window.
2. Enter the information for the new record.
3. Choose and enter parameter information as appropriate.

When only one record is possible, [New Record] disappears after you configure the first server.

8.5.2 Configuring Server and Security Parameters

Use the Server/Security tab to perform the following tasks:

• Configure Server/Security parameters.
• Configure IP ranges.
• Set up the host name lists.
• Use the Active IP Snapshot window.
• Preload MAC addresses.

To configure the server parameters using the Server/Security tab of the GUI, follow these steps:

1. Click the Server/Security tab.
2. Choose a parameter class from the drop-down list.
3. Choose the parameter you want to change.

You can change any or all of the Server/Security parameters described in this section.

Accept Client Name

Specifies whether the server assigns names to client machines according to a policy that is established on the server by the system manager.

Even when this capability is enabled, the server ignores the client-suggested name if it is already in use by another client in the same domain.

If the server is unable to find a name for the client by applying this policy, it will take one of the following actions depending upon the specified value. The valid values are:

False:	Assign a name from the NAMEPOOL. file if an IP address lookup does not return an associated name. Default.
True:	Use the name the client suggests for itself, if specified.

Assign Name by Hardware Addr

Specifies whether you can assign host names by the hardware address. If you choose True, the client computer always has the same name, even if its IP address changes; however, to do so, the client must remain in the same domain.

This option is appropriate for sites supporting dynamic updating of the name service. When you select this policy, the server maintains a binding of the client's unique identifier to the name the client first acquires.

If the name service does not dynamically update, the new name-IP address mapping implied by this policy is not available to other clients until you bring the name service up to date by another mechanism. This means dumping data from the database and using it to update the name service manually. The following are valid values:

False:	Disable assignment of host names by hardware addresses. Default.
True:	Enable assignment of host names by hardware addresses. Use the naming method defined in the NAMEPOOL. file.

Assign Name by IP Addr

Specifies whether you can assign host names by an IP address. If you choose True, the client receives its name from the name service as a result of a gethostbyaddr routine call. Also, when a client computer moves, it can receive a new name from the name service. The following are valid values:

False:	Host names cannot be assigned by IP addresses. The DHCP server does not issue a gethostbyaddr routine call. Instead, the session uses the naming method defined in the NAMEPOOL. file.
True:	Host names can be assigned by IP addresses. Default.

Auto Release Old Lease

Set this to True if you want to automatically delete leases when the client changes its network. For example, if the client:

• Receives an address on subnet A
• Then moves to subnet B

The server releases the leased IP address on subnet A even though the leased IP address on subnet A is still valid.

The default setting is False.

Note Some hardware configurations use a MAC address or client identifier that is the same regardless of which interface you are configuring. To the DHCP server, two interfaces of a client of this type can appear to be a single client that has changed networks. Do not autorelease these leases.

Auto Reread Config File

Instructs the server to see if the DHCPCAP. file has changed, indicated by the timestamp. This occurs each time a client requires a configuration. If the file changes, the server rereads and reparses the DHCPCAP. file.

The default is True.

Auto Synchronize Database

Choose True to flush the server database to disk after each update. This makes the server more reliable if there is a failure such as a system crash or unintentional power shutdown. Setting this parameter to True can slow down the server.

The default is False.

BOOTP Addr From Pool

Specifies whether the DHCP server does not require a preestablished binding for BOOTP clients. When none exists, the server allocates an address from the pool to the client. Because BOOTP does not understand the concept of lease times, all such allocations are permanent regardless of the lease times specified elsewhere in the database.

When you disable BOOTP Addr From Pool, the Server only supports BOOTP clients whose IP address is configured into the database. This means the binding of the IP address to the client must be preestablished. The address must be consistent with the network to which the client is attached. See Section 8.6 for information on how to preestablish a binding between a MAC address and an IP address. The following are valid values:

False:	Do not pick an address from a pool. Requires a preestablished binding. Default.
True:	Pick an address from a pool. Does not require a preestablished binding.

BOOTP Client Lease Extension

TCP/IP Services does not currently support this parameter.

When you set this parameter to a value above zero, the server grants Finite leases to BOOTP clients. BOOTP clients do not know this, so before the server can reuse these leases, it must ping the IP address. If the server hears a reply, it extends the lease by the time interval (in seconds) specified by this parameter.

The default value is 0 seconds.

BOOTP Compatibility

DHCP can serve BOOTP clients as well as DHCP clients. The following are valid values:

False:	The server should act as a DHCP server only.
True:	The server should also act as a BOOTP server. Default.

Bootfile not sent as option

Because the DHCP clients normally do not require bootfile names, the space reserved for this purpose (the "file" field) in reply packets is used by JOIN as an extension of the DHCP options field. This arrangement permits the client to receive more configuration information than would otherwise be possible in a standard-sized DHCP packet.

Enabling this parameter sends the bootfile name in the "file" field, instead of as a DHCP option. Certain network computers (NCs) expect to find the bootfile information in the "file" field and will not successfully load their OS images unless this parameter is set to True. Note: BOOTP clients always receive a bootfile name in the "file" field, regardless of the state of this option.

Canonical Name

Overrides the value normally returned by a gethostname routine call (default). Primarily used for multihomed hosts with a canonical name corresponding to an interface that is not recognized by DHCP (for example, ATM interfaces) and for high-availability servers that have per-service IP addresses that differ from a physical IP host address. The following are valid values:

False:	Use the host name returned by a gethostname routine call. Default.
True:	Use the specified canonical host name.

Check BOOTP Client Net

Before a BOOTP client is given a hard-wired IP address, the server makes sure that the client is connected to the logical IP network for which the address is valid. If the client is not connected, the server logs an error and does not send a response to the client.

For this to work properly, the NETMASKS. file must contain the network numbers and masks for any nonstandard IP Class A, B, or C configuration. The following are valid values:

False:	Do not check the IP network of the address. Default.
True:	Check the IP network of the address.

DNS expiration tracks DHCP lease

This parameter implies that SIG resource records for DNS are updated with expiration times that match the DHCP client's lease time. If a client sends a "DHCP release", the lease is prematurely expired and the SIG record is marked as expired. In order to reduce the amount of traffic between DHCP and DNS, the default value is False.

This policy affects only installations that use the Dynamic DNS option.

Default Lease Time

Specifies the value used on all leases for clients that have no other value explicitly configured. Enter the lease time of the IP address granted to a client.

The default lease time is one day.

Expand BOOTP Packet

Expands the BOOTP reply packet to 548 bytes. Applies to BOOTP clients only. The following are valid values:

False:	All replies to BOOTP clients are 300 octets or a size equal to the size of the packet received, whichever is larger. Default.
True:	All replies to BOOTP clients are expanded to 548 bytes.

Force Broadcast Reply

The DHCP server generally sends unicast reply packets in response to client packets. This toggle tells the server to send broadcast reply packets instead of unicast reply packets. The following are valid values:

False:	Forces the DHCP server to use unicast reply packets. Default.
True:	Forces DHCP server to broadcast reply packets to the client, even when the server could use unicast replies.

Free List Size

Specifies the size of the internal array specifying the number of address blocks held on the free list. If this number is too high, the server will lose previous allocations of expired leases quickly. If this number is too low, performance can suffer.

---

Previous

Next

Contents

Index