Previous Page TOC Index Next Page

DHCP/BOOTP Server

Introduction

This chapter describes the DHCP/BOOTP Server. It combines the Dynamic Host Configuration Protocol (DHCP) server with the bootstrap protocol daemon (BOOTPD). It is divided into the following sections:

DHCP and BOOTP

DHCP is the Dynamic Host Configuration Protocol. It centralizes and automates TCP/IP network configuration. The DHCP Server dynamically allocates IP addresses for hosts on the network from an available pool of addresses. In this way, new hosts or hosts that are frequently relocated can automatically get new IP addresses for a certain lease period.

DHCP is an extension of the Internet Bootstrap Protocol (BOOTP). DHCP offers a network host a temporary lease rather than an ownership of an IP address. The lease identifies the duration for which the client can safely use its dynamically assigned IP address. Lease lengths generally depend on the number of network users (crowding of the network) and the number of available IP addresses the DHCP server can assign. The network manager sets the lease length through parameters.

BOOTP uses UDP/IP to allow diskless systems to find their IP addresses, addresses of boot servers, and names of boot files. BOOTP can supply other client information, such as the addresses of name servers, gateways, and LPD servers.

In TCPware, the DHCP Server (DHCPD) is combined with the BOOTP Server (BOOTPD) to form the DHCP/BOOTP Server (DHCPD/BOOTPD).

Note! DHCP uses DNS for host names and IP addresses; thus, a malfunction in your DNS server can affect the DHCP server.

DHCP Process

DHCP goes through an initializing, selecting, requesting, binding, renewal, rebinding, and expiration cycle when negotiating for an IP address, as shown in Figure 2-1. The process is basically as follows:

1

The client just added or relocated on the network requests an IP address by broadcasting a DHCPDISCOVER message to the local subnet over the well-known BOOTP server port. (The client can also go through a BOOTP router or relay agent to forward the DHCPDISCOVER to additional remote DHCP servers.) This is the initializing state.

2

The participating DHCP servers respond with a DHCPOFFER message if they have a valid configuration for the client. The client may get many of these messages, which contain the IP address and configuration data. (The servers make sure to reserve the addresses so as not to accidentally offer them to another client.) At this point the client enters the selecting state.

3

After selecting an address, the client broadcasts the selected address and name of the "winning" server (DHCP Server 1 in Figure 2-1) using a DHCPREQUEST message. This is the requesting state. All the other servers can now safely unreserve their addresses.

4

Server 1 sends the client a DHCPACK (acknowledgment) message with the negotiated IP address, the lease, and the network configuration parameters. The client now enters the binding state and can fully use the assigned IP address.

5

About halfway through the lease, the client sends Server 1 another DHCPREQUEST for a lease renewal, and enters the renewal state. If the server deems the lease renewable, it sends back another DHCPACK to update the lease (including any new parameters). The client now returns to the binding state, as in Step 4.

6

If the client cannot renew the lease (such as if Server 1 is down), the client waits until about 87.5% of the way through the lease and broadcasts another DHCPREQUEST to all DHCP servers. Any server can now return a DHCPACK containing the extended lease and updated parameters. This is the rebinding state.

7

When the lease reaches 100% expired, or a server sends back a DHCPNAK negative acknowledgment message, the client must give up the IP address. It then returns to the initializing state and has to start the address negotiation over again.

Figure 2-1 DHCP Address Request and Allocation Process

DHCP is defined in RFC 2131 and RFC 2132. Refer to them for more information.

Two DHCP servers are recommended for a network. The benefit of having more than one server is if one fails another is available to continue processing requests, ensuring that all hosts (old and new) are serviced continuously. Refer to DHCP Safe-failover Introduction for more information.

DHCP Administration

You can administer the DHCP server using the following TCPware Network Control Utility (NETCU) commands:

Command Description

RELEASE DHCP ip-address

Forces the DHCP server to act as if it heard a DHCPRELEASE message from the client for the given IP address.

REMOVE DHCP ip-address

Synonym for RELEASE DHCP.

SET DHCP/DEBUG=value

Sets the debug logging level to the given value.

SET DHCP/NEWLOG

Starts a new debug log file.

SET DHCP/PARTNERDOWN

For Safe-failover DHCP: causes the DHCP server to transition into Partner Down state.

STOP/DHCP

Causes the server to shut down.

SHOW DHCP/ALL

Displays SHOW DHCP/SUBNET output for all subnets, plus information about static assignments.

SHOW DHCP/CLIENT_IDENTIFIER=client-id

Displays all lease binding and static assignment details for the given client ID.

SHOW DHCP/CONFIGURATION

Writes all configuration and lease information to a dump file.

SHOW DHCP/HARDWARE_ADDRESS=hardware-address

Displays all lease binding and static assignment details for the given hardware address.

SHOW DHCP/IP_ADDRESS=ip-address

Displays lease binding details for the given IP address. Static assignments are not supported.

SHOW DHCP/LEASES

Displays brief information about each lease.

SHOW DHCP/POOLS

Displays address pool availability.

SHOW DHCP/STATUS

Checks if the DHCP server is running.

SHOW DHCP/SUBNET=ip-address

Displays brief information about each IP address in the same shared network as the given IP address.

SHOW DHCP/VERIFY

Checks the syntax of the configuration file.

SHOW DHCP/VERSION

Displays the version of the DHCP server.

See the SHOW DHCP, SET DHCP, RELEASE DHCP, REMOVE DHCP, and STOP/DHCP command descriptions in the NETCU Command Reference.

DHCP Configuration

You can configure the DHCP server using CNFNET by typing @TCPWARE:CNFNET DHCP.

You can configure the following items:

See the DHCP configuration description in the Installation and Configuration Guide.

DHCP Conversion Tool

The DHCP_CONVERSION_TOOL assists in changing from the DHCP server in TCPware V5.3 and earlier to the DHCP server in TCPware V5.4. This tool converts the configuration file and lease file from the 5.3 DHCP server to the format of the configuration and lease files of the 5.4 DHCP server. It is run automatically by the command procedure that starts the DHCP server, TCPWARE:DHCP_CONTROL.COM. However, it is recommended that you run the conversion tool and verify the output ahead of time.

The conversion tool reads the old DHCP configuration file or BOOTP configuration file and writes out a configuration file in the new format. All information from the old configuration file is in the new file. Information that does not have an equivalent in the new configuration file is represented with comment lines.

The conversion tool then reads the old lease file and writes out a lease file in the new format.

The old configuration and lease files are retained in their original location so you can use them to validate the new configuration and lease files.

You can also run the conversion tool directly by specifying the names of the input and output files at the command prompt. If they are not specified, the tool prompts you for them. Enter "NONE" for the file name if you do not have the input file.

For example: if you do not have a lease file, then enter: 

$ dhcpconvert :== $tcpware:dhcp_conversion_tool.exe

$ dhcpconvert dhcptab. none dhcpd.conf dhcpd.leases

Enter a question mark (?) to get help for the tool.

The default file names are:

TCPWARE:DHCPTAB.

The old DHCP configuration file.

TCPWARE:BOOTPTAB.

The old BOOTP configuration file. Read only if the DHCPTAB file does not exist.

TCPWARE:DHCPD.CONF

The new DHCP configuration file.

TCPWARE:DHCP_LEASE.DAT

The old DHCP lease file containing the lease status.

TCPWARE:DHCPD.LEASES

The new DHCP lease file.

Warning! Review the output lease file carefully. The old TCPware lease file does not contain the hardware type, so the conversion tool usually uses ethernet. If you are using a token ring network, change the 'hardware ethernet' statements to 'hardware token-ring' statements. The old TCPware lease file also does not contain whether the ID was a hardware address or client identifier, so review carefully all 'uid' and 'hardware' statements.

Introducing the Configuration File

TCPware supplies a template DHCP configuration file, TCPWARE:DHCPD_CONF.TEMPLATE, that contains comments and a number of examples to help you enter information for your hosts. Using this template as a guide, create a DHCP configuration file at TCPWARE:DHCPD.CONF (with any text editor) containing the entries you need for your network and hosts.

The dhcpd.conf file is a free-form ASCII text file. The file may contain extra tabs and new lines for formatting purposes and comments may be placed anywhere within the file (except within quotation marks). Comments begin with the # character and end at the end of the line. See Example 2-2. Keywords in the file are case-insensitive.

The file consists of a list of statements specify which fall into two categories: parameters and declarations.

Parameter statements always specify one of the following:

Global parameters are at the beginning of the file. Some examples of global parameters are the organization's domain name and the addresses of the name servers (if they are common to the entire organization).

It is legal to specify host addresses in parameters as domain names rather than as numeric IP addresses. If a given hostname resolves to more than one IP address (for example, if that host has two ethernet interfaces), both addresses are supplied to the client.

Both the shared-network statement and the subnet statement can have parameters.

The most obvious reason for having subnet-specific parameters is that each subnet, of necessity, has its own router; for example: 

option routers 204.254.239.1;

Note that the address is specified numerically; this is not required. If you have a different domain name for each interface on your router, it is appropriate to use the domain name for that interface instead of the numeric address. However, there may be only one domain name for all a router's IP addresses, and it would not be appropriate to use that name here.

Parameters starting with the option keyword correspond to actual DHCP options. Parameters that do not start with the option keyword either control the behavior of the DHCP server (for example, how long a lease the DHCP server will give out), or specify client parameters that are not optional in the DHCP protocol (for example, server-name and filename).

Each host can have host-specific parameters. These could include such things as the:

In general, any parameter can appear where ever that parameters are allowed, and will be applied according to the scope in which the parameter appears.

All parameters must be specified first before you can specify any declarations that depend on those parameters. Parameters should be set inside declarations so they can be set on a per-subnet or a per-host basis.

Declarations are used to:

Declarations about network topology include the subnet and the shared-network declarations.

For every subnet to be served, and for every subnet connected to the DHCP server, there must be one subnet declaration. This declaration tells the DHCP server how to recognize that an address is on that particular subnet. A subnet declaration is required for each subnet even if no addresses is dynamically allocated on that subnet.

There are different declarations required for different situations. The following are the basic declarations in a configuration file.

Declarations How Used

range

For clients with dynamically assigned addresses, a range declaration must appear within the subnet declaration.

host

For clients with statically assigned addresses, or for installations in which only known clients are served, each client must have a host declaration.

group

If parameters are applied to a group of declarations that are not related strictly on a per subnet basis, the group declaration can be used.

Some installations have physical networks allowing more than one IP subnet to operate. For example, if your site has a requirement that 8-bit subnet masks be used, but a department with a single physical ethernet network expands beyond 254 nodes, you may have to run two 8-bit subnets on the same ethernet until a new physical network is added. In this case, you can enclose the subnet declarations for the two networks in a shared-network declaration.

If you have clients in a department on more than one subnet, it may be best to offer those clients a uniform set of parameters that are different than what would be offered to clients from other departments on the same subnet.

When a client is to be booted, its boot parameters are determined by consulting the:

1

Client’s host declaration (if any)

2

Group declaration (if any) that enclosed the host declaration

3

User class declaration (if any) (DHCP only)

4

Vendor class declaration (if any) (DHCP only)

5

Subnet declaration for the subnet on which the client is booting

6

Shared-network declaration (if any) containing that subnet

7

Top-level parameters that may be specified outside of any declaration

When searching for a host declaration, the DHCP server looks for one with a fixed-address parameter that matches the subnet or shared network on which the client is booting. If no such entry is found, it looks for an entry with no fixed-address parameter. If no such entry is found again, the DHCP server acts as if there is no entry in the dhcpd.conf file for that client, even if there is an entry for that client on a different subnet or shared network.

Imagine that you have a site with a lot of NCD X-Terminals. These terminals come in a variety of models, and you want to specify the boot files for each model. You could have host declarations for each server and group them by model:

Example 2-1 Host Declarations

group {

      filename "Xncd19r";

      next-server ncd-booter;

      host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }

      host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }

      host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }

    }

    group {

      filename "Xncd19c";

      next-server ncd-booter;

      host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }

      host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }

    }

    group {

      filename "XncdHMX";

      next-server ncd-booter;

      host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }

      host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }

      host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }

}

Verifying the DHCP Configuration

After modifying the configuration file, it is good practice to verify the syntax by entering the following NETCU command: 

$ NETCU SHOW DHCP/VERIFY[/FILENAME=<config-file>] -

_$ [/OUTPUT=<output-file>]

This command causes the DHCP server to run enough to read and parse the configuration file. The DHCP server displays a copyright notice and a message for each syntax error encountered. If the DHCP server displays only the copyright notice, the configuration file has no syntax errors.

The /FILENAME qualifier optionally specifies where the configuration file is. If you do not specify the /FILENAME qualifier, the DHCP server reads the default configuration file TCPWARE:DHCPD.CONF. The /OUTPUT qualifier optionally sends command output to the specified file.

Reloading the DHCP Configuration

If you modify TCPWARE:DHCPD.CONF after starting the DHCP server, reload the DHCP configuration by restarting the DHCP server by using @TCPWARE:RESTART DHCP. When the DHCP server restarts, it rereads the configuration file.

DNS Dynamic Updates Within DHCP

The DHCP server performs dynamic updates to DNS using DNS's dynamic updating functionality. To be sure that updates are allowed from the DHCP server, see Chapter 1, Domain Name Services. The allow-update { <address_match_list> }; statement in the Zone section enables the DNS server to allow updates from that system.

The following statements in the DHCP server configuration file are related to dynamic updating:

Dynamic updates can be enabled or disabled by using the allow/deny dynamic-update statement in the configuration file. The default is to not perform dynamic updates. Dynamic updates can be turned on or off on a per subnet basis.

Note! Dynamic updates are done for statically assigned IP addresses for DHCP clients, dynamically leased IP addresses for DHCP clients, and dynamically assigned IP addresses for BOOTP clients. The updates are not done for static assignments to BOOTP clients.

When dynamic updating is enabled, the DHCP server determines the client's Fully Qualified Domain Name (FQDN) and assigns it an IP address. The FQDN is determined either by what the client sends or by what is in the configuration file. This behavior is controlled by the allow/deny name-by-client statement in the configuration file.

The FQDN and IP address are used in the dynamic update to create a PTR resource record (RR). The DHCP server also optionally creates an A RR. This option is enabled or disabled by using the allow/deny update-A-record statement in the configuration file. The default is to not create the A RR. This can be set on a per subnet basis. See Chapter 1, Domain Name Services for information about PTR resource records and A resource records.

When dynamic updating is allowed, the DHCP server adds the resource records whenever an IP address is leased to a client. The RRs are deleted if the IP address is released or if the IP address is leased to a different client.

Host Name Generation

Some DHCP clients require that the server send them a host name. The TCPware DHCP server can generate a host name if it cannot get the host name in another way. The generated host name can contain parts of the host's IP address, client ID, and/or MAC address. This host name is sent to the client and is combined with the domain name to create the Fully Qualified Domain Name (FQDN) required for dynamic DNS updates. See the DNS Dynamic Updates Within DHCP section. As described in the DNS updates section, the allow/deny name-by-client statement in the configuration file controls whether the DHCP server uses information from the client to determine the host name and FQDN.

The DHCP server generates a host name if it is enabled to do so and either of the following is specified:

To enable the DHCP server to generate host names, specify in the configuration file an option host-name statement with a value containing certain key values in addition to any characters that are valid for the host-name option (see Table 2-2). The option host-name statement can be specified for example at the top level in a subnet statement, or in a host statement.

The key values are as follows. You can include more than one in the same host-name value. Note that some of these do not by themselves generate a unique identifier.

Key Meaning

%A

First byte of the host's IP address.Example: for address 10.24.25.201, the key would return 10.

%B

Second byte of the host's IP address.Example: for address10.24.25.201, the key would return 24.

%C

Third byte of the host's IP address.Example: for address 10.24.25.201, the key would return 25.

%D

Fourth byte of the host's IP address.Example: for address 10.24.25.201, the key would return 201.

%H

Host part of the host's IP address.Example: for address 10.24.25.201 with subnet mask 255.255.0.0, the key would return 6601.

%I

Client Identifier sent by the host.

%-I

Client ID as above, except that hyphens (-) are used to separate each byte.

%M

MAC address of the host.

%-M

MAC address of the host, as above, except that hyphens (-) are used to separate each byte.

%N

Host name sent by the client, if any. If none, "Host".

%S

Subnet part of the host's IP address.Example: for address 10.24.25.201 with subnet mask 255.255.0.0, the key would return 102400.

%-S

Subnet part of the host's IP address, as above, except that hyphens (-) are used to separate each byte. For example: 10-24-0-0.

You can intersperse string constants such as hyphens between key definitions. However, if the generated host name exceeds 63 characters, it is truncated. Here is an example host-name statement: 

option host-name "Host%H-%-S";

For a lease pool defined with an address range of 192.168.11.6 through 192.168.11.10 and a subnet mask of 255.255.255.0, the DHCP server generates the following host names: 

Host6-192-168-11-0

Host7-192-168-11-0

Host8-192-168-11-0

Host9-192-168-11-0

Host10-192-168-11-0

The %N key allows you to use the host name as sent by the client (option 12) and then add something unique to it to generate a unique name. For example, if multiple clients all send the name "dilbert" you can make them unique by appending the MAC (hardware) address, as follows: 

deny name-by-client;

option host-name "%N-%M";

This would generate the host name "dilbert-010203040506" for a client with hardware address 01:02:03:04:05:06.

Configuration File Declarations and Parameters

Table 2-1 describes the declarations and parameters you can use in a configuration file.

See Table 2-8 for a list of DHCP Safe-failover-related configuration file statements.

Table 2-1 DHCP Statements
Statement Description

allow and deny

Use the allow and deny statements to control the behavior of the DHCP server.

Use the unknown-clients flag to tell the DHCP server to dynamically assign addresses to unknown clients or to not assign addresses to unknown clients. The default is to allow dynamic address assignments to unknown clients.

Use the bootp flag to tell the DHCP server to respond to bootp queries or to not respond to bootp queries. The default is to allow bootp queries.

Use the booting flag to tell the DHCP server to respond to queries from a particular client or to not respond to queries from a particular client. This keyword only works when it appears in a host declaration. The default is to allow booting. If it is disabled for a particular client, that client will not be able to get an address from the DHCP server.

Use the dynamic-update flag to tell the DHCP server to perform dynamic DNS updates or to not perform them. The default is to deny dynamic DNS updates.

Use the name-by-client flag to tell the DHCP server to determine the hostname and Fully Qualified Domain Name (FQDN) for dynamic DNS updates from information sent by the client or from information in the configuration file. The default is to deny use of client-specified information.

Use the dhcpinform flag to tell the DHCP server to respond to DHCPINFORM messages or to not respond. The default is to allow DHCPINFORM messages.

allow and deny(continued)

Use the update-A-record flag to tell the DHCP server to update the A resource record or not when performing DNS updates (the PTR resource record is always updated). The default is to deny updating the A resource record.

Use the ras-servers flag to tell the DHCP server to respond to queries from Microsoft (R) NT RAS Servers or to not respond to NT RAS queries. The default is to allow NT RAS queries. 

allow unknown-clients;     allow dynamic-update;
deny unknown-clients;      deny dynamic-update;

allow bootp;               allow name-by-client;
deny bootp;                deny name-by-client;

allow booting;             allow update-A-record;
deny booting;              deny update-A-record

allow dhcpinform;          allow ras-servers;
deny dhcpinform;           deny ras-servers;

always-reply-rfc1048

Some BOOTP clients expect RFC 1048-style responses, but do not follow RFC 1048 rules when sending their requests. You can determine if a client is having this problem:

  • if it is not getting the options you have configured for it.
    and
  • if you see in the server log the message "(non-rfc1048)" printed with each BOOTREQUEST that is logged.
If you want to send RFC 1048 options to this kind of client, set the always-reply-rfc1048 option in that client's host declaration. The DHCP server responds with an RFC 1048-style vendor options field. This flag can be set in any scope, and affects all clients covered by that scope. 
always-reply-rfc1048 flag;

authoritative;
not authoritative;

The DHCP server normally assumes the configuration information about a given network segment is correct and is authoritative. So if a client requests an IP address on a given network segment that the server knows is not valid, the server responds with a DHCPNAK message, causing the client to forget its IP address and try to get a new one.

If a DHCP server is being configured by someone other than the network administrator and who does not want to assert this level of authority, the statement not authoritative should be written in the appropriate scope in the configuration file.

Usually, writing not authoritative at the top level of the file should be sufficient. However, if a DHCP server is to be set up so that it is aware of some networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.

The most specific scope for which the concept of authority makes sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement. It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.

Note: For network segments for which the DHCP server is not authoritative, you may want to specify deny dhcpinform.

default-lease-time

Time is the length (in seconds) that the DHCP server assigns to a lease if the requesting client did not ask for a specific amount of time for the lease to be active. The infinite lease value is 0. The default is 12 hours.

You should set the value of default-lease-time no larger than the value of max-lease-time. 

default-lease-time time;

dynamic-bootp-lease-cutoff

Use the dynamic-bootp-lease-cutoff statement to set the ending time for all leases dynamically assigned to BOOTP clients. By default, the DHCP server assigns infinite leases to all BOOTP clients because they do not have any way of renewing leases, and do not know that their leases could expire. However, it may make sense to set a cutoff date for all BOOTP leases. For example, the end of a school term, or the time at night when a facility is closed and all machines are required to be powered off.

Date should be the date all assigned BOOTP leases will end. The date is specified in the form: 

W YYYY/MM/DD HH:MM:SS

W is the day of the week, from zero (Sunday) to six (Saturday).
YYYY is the year, including the century.
MM is the number of the month, from 01 to 12.
DD is the day of the month, counting from 01.
HH is the hour, from 00 to 23.
MM is the minute, from 00 to 59.
SS is the second, from 00 to 59.
The time is always in Greenwich Mean Time, not local time. 

dynamic-bootp-lease-cutoff date;

dynamic-bootp-lease-length

Use the dynamic-bootp-lease-length statement to set the length of leases dynamically assigned to BOOTP clients. You may be able to assume that a lease is no longer in use if its holder has not used BOOTP or DHCP to get its address within a certain time period. The length of the time period is your judgment call.

Specify length in seconds. The infinite lease value is 0. If a BOOTP client reboots during a timeout period, the lease duration is reset to length so a BOOTP client that boots frequently never loses its lease. This parameter should be adjusted with extreme caution.

The default is an infinite lease. 

dynamic-boot-lease-length length;

filename

Use the filename statement to specify the name of the initial boot file that is to be loaded by a client. The filename should be recognizable to whatever file transfer protocol the client can be expected to use. 

filename filename;

fixed-address

Use the fixed-address statement to assign one or more fixed IP addresses to a client. It should only appear in a host declaration. With more than one address supplied, the client is assigned the address that corresponds to the network on which it is booting. If none of the supplied addresses are on the network the client is booting from, the client will not match the host declaration containing that fixed-address statement. Each address should be either an IP address or a domain name that resolves to one or more IP addresses. 

fixed-address address [,address];

get-lease-hostnames

Use the get-lease-hostnames statement to tell the DHCP server to look up the domain name corresponding to each address in the lease pool and use that address for the DHCP hostname option.

If flag is true, the lookup is done for all addresses in the current scope.

If flag is false (the default), lookups are not done. 

get-lease-hostnames flag;

group

Use the group statement to apply one or more parameters to a group of declarations. You can use it to group hosts, shared networks, subnets, or other groups. 

group {[parameters] [declarations]}

hardware

Use the hardware clause inside a host statement to specify the network hardware address of a BOOTP or DHCP client.

hardware-type must be the name of a physical hardware interface type. Ethernet, Token-Ring, and FDDI are the only recognized types.

The hardware-address should be a set of hexadecimal octets (numbers from 0 through ff) separated by colons (:). 

hardware hardware-type hardware-address;

host

You may specify host statements for BOOTP or DHCP clients, although this is not required unless booting is only enabled for known hosts, or, if you want to give the BOOTP or DHCP client a fixed address.

hostname should be a name identifying the host. hostname is required.

If you want to boot a DHCP or a BOOTP client on more than one subnet with fixed addresses, you can either specify:

  • More than one address in the fixed-address parameter, or
  • More than one host statement.
You should use multiple host statements if client-specific boot parameters must change because of the network the client is attached to.

If you want to boot a client using a fixed address on one subnet, but the client should be allocated a dynamic address on another subnet, then specify a host statement without a fixed-address clause in addition to the host statement with the fixed address for the first subnet.

A Host declaration is matched to actual DHCP or BOOTP clients by matching the dhcp-client-identifier option specified in the host declaration to the one supplied by the client. If the host declaration or the client does not provide a dhcp-client-identifier option, the hardware parameter in the host declaration is matched to the network hardware address supplied by the client.

Since BOOTP clients do not normally provide a dhcp-client-identifier, the hardware address must be used for all host statements for clients using the BOOTP protocol. 

host hostname {[parameters][declarations]}

max-delayed-acks

To improve performance under very heavy loads, the DHCP server delays sending DHCPACK messages by up to 2 seconds. All DHCPACKs accumulated in that time are sent in a batch. The max-delayed-acks parameter specifies the maximum number of DHCPACKs to batch up. The default is 8. To disable the delaying of DHCPACKs, specify a value of 1. 

max-delayed-acks count;

max-lease-time

Time is the maximum amount of time (in seconds) a lease is allowed to be. The infinite lease value is 0. The default is 24 hours.

You should set the value of max-lease-time at least as large as default-lease-time. 

max-lease-time time;

next-server

Use the next-server statement to specify the host address of the server from where the client will load the initial boot file (specified in the filename statement).

server-name should be a numeric IP address or a domain name. The DHCP server’s IP address is used if no next-server parameter applies to a given client. 

next-server name;

option

This statement specifies actual DHCP protocol options to send to the client. The option statement is described in the next section.

ping

The DHCP server uses ping to check if a particular IP address is in use by sending a packet of information and waiting for a response. This statement turns ping on and off. The default is on. 

ping flag;

ping-retries

This statement defines the number of times the DHCP server pings an IP address before it concludes that the address is not in use. The default is 1. 

ping-retries count;

ping-timeout

This statement defines the time (in seconds) that ping should wait for a response. The default is 1 second. 

ping-timeout time;

range

There must be at least one range statement for any subnet with addresses that can be dynamically assigned. The range statement gives the lowest and the highest IP addresses available in a range. All IP addresses in the range should be in the subnet where the range statement is declared. The dynamic-bootp flag may be specified if addresses in the selected range can be dynamically assigned to BOOTP clients as well as to DHCP clients.

Omit high-address when specifying a single address. 

range [dynamic-bootp] low-address [high-address];

requested-options-only flag;

Some DHCP clients cannot handle receiving any options other than the ones they request or a specific list of options. In order to send just the options requested by the client, specify "requested-options-only true;" in the configuration for that client. In order to send a specific set of options, you can set requested-options-only to true and specify the dhcp-parameter-request-list option. For example, the following sends only the subnet-mask, routers, and domain-name-servers options to the client (assuming they are defined in the configuration file): 

host restricted {
     hardware ethernet 01:02:03:04:05:06;
     option dhcp-parameter-request-list 1, 3, 6;
     requested-options-only true;
}

server-identifier

The server-identifier statement can be used to define the value that is sent in the DHCP Server Identifier option. The value specified MUST be an IP address for the DHCP server, and must be reachable by all clients which it is sent to.

The use of the server-identifier statement is not recommended. The only reason to use it is to force a value other than the default value to be sent on occasions where the default value would be incorrect. The default value is the first IP address associated with the physical network interface on which the request arrived.

The usual case where the server-identifier statement needs to be sent is when a physical interface has more than one IP address, and the one being sent by default is not appropriate for some or all clients served by that interface.

Another case is when an alias is defined for the purpose of having a consistent IP address for the DHCP server, and it is desired that the clients use this IP address when contacting the server.

Supplying a value for the dhcp-server-identifier option is equivalent to using the server-identifier statement. 

server-identifier hostname;

server-name

Use the server-name statement to inform the client of the server’s name from which it is booting. name should be the name provided to the client. 

server-name name;

shared-network

Use this statement to inform the DHCP server that some IP subnets share the same physical network. Declare all subnets in the same shared network within a shared-network statement.

Parameters specified in the shared-network statement will be used when booting clients on those subnets unless parameters provided at the subnet or host level override them. If more than one subnet in a shared network has addresses available for dynamic allocation, those addresses are collected into a common pool. There is no way to specify which subnet of a shared network a client should boot on.

Name should be the name of the shared network. Make the name descriptive as it will be used when printing debugging messages. Give it a syntax of a valid domain name (although it will never be used as such), or any arbitrary name enclosed in quotation marks. 

shared-network name {[parameters] [declarations]}

subnet

This statement contains information specific to a subnet. The information communicates the following to DHCP:

  • Enough information for DHCP to determine if an IP address is on that subnet.
  • What the subnet-specific parameters are.
  • What addresses may be dynamically allocated to clients booting on that subnet.
Use the range declaration to specify what addresses are available to be dynamically allocated to clients booting on the subnet.

Two things are required to define a subnet:

  • The subnet-number
  • The netmask
The subnet-number and the netmask entry is an IP address or domain name that resolves to the subnet-number or the netmask of the subnet being described. The subnet-number and the netmask are enough to determine if any given IP address is on the specified subnet.

Note: A netmask must be given with every subnet declaration. If there is any variance in subnet masks at a site, use a subnet-mask option statement in each subnet declaration to set the desired subnet mask. The subnet-mask option statement overrides the subnet mask declared in the subnet statement. 

subnet subnet-number netmask
netmask {[parameters][declarations]}

use-host-decl-names

If the use-host-decl-names parameter is true, the name provided for each host declaration is given to the client as its hostname. The default is false. For example, 

group {
use-host-decl-names on;
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}
is equivalent to 
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name “joe”;
}
An option host-name statement within a host declaration overrides the use of the name in the host declaration. 
use-host-decl-names flag;

use-lease-addr-for-default-route

If the use-lease-addr-for-default-route parameter is true in a given scope, the IP address of the lease being assigned is sent to the client instead of the value specified in the routers option (or sending no value at all). This causes some clients to ARP for all IP addresses, which can be helpful if your router is configured for proxy ARP.

If use-lease-addr-for-default-route is enabled and an option routers statement are both in scope, the routers option is preferred. 

use-lease-addr-for-default-route flag;

user-class

Use this statement to specify parameters and options for clients with a particular user class. User class is sent by the client in the User Class Information option. (DHCP only) 

user-class “user-class-identifier”
{[parameters] [declarations]}

vendor-class

Use this statement to specify parameters and options for clients with a particular vendor class. Vendor class is sent by the client in the Vendor Class Identifier option. (DHCP only) 

vendor-class “vendor-class-identifier” 
{[parameters] [declarations]}

DHCP Options

The Dynamic Host Configuration protocol allows the client to receive options from the DHCP server describing the network configuration and various services that are available on the network. When configuring the DHCP server, options must often be declared. The syntax for declaring options, and the names and formats of the options that can be declared, are in Table 2-2.

DHCP option statements always start with the keyword option, followed by an option name, which is followed by option data. Only options needed by clients must be specified.

Option data comes in these formats:

If the option value is a list (such as for the routes option), you must list them in the configuration file in the order you want the client to use the values. The DHCP server does not re-order them.

Table 2-2 describes the standard DHCP options. Underlined items indicate user input items.

Table 2-2 DHCP Options
Option Description

option all-subnets-local flag;

Use this option to indicate whether or not to assume all subnets of the client’s IP network use the same MTU as the client’s subnet.

  • ON means assume all subnets share the same MTU.
  • OFF means assume some subnets have smaller MTUs.

option arp-cache-timeout uint32;

Use this option to identify the timeout (in seconds) for ARP cache entries.

option bootfile-name string;

Use this option to identify a bootstrap file. If this option is supported by the client, it should have the same effect as the filename declaration. BOOTP clients are unlikely to support this option. Some DHCP clients support it; others require it.

option boot-size uint16;

Use this option to specify the length in 512-octet blocks of the client’s default boot image.

option broadcast-address ip-address;

Use this option to identify the broadcast address in use on the client’s subnet. See STD 3 (RFC 1122), section 3.2.1.3 for legal values for broadcast addresses.

option cookie-servers ip-address [, ip-address ...];

Use this option to list RFC 865 cookie servers in order of preference.

option default-ip-ttl uint8;

Use this option to identify the default time-to-live the client should use on outgoing datagrams.

option default-tcp-ttl uint8;

Use this option to identify the default TTL to use when sending TCP segments. The minimum value is 1.

option dhcp-client-identifier data-string;

Use this option to specify a DHCP client identifier only in a host declaration. The DHCP server uses it to locate the host record by matching against the client identifier.

option dhcp-max-message-size uint16;

Use this option to specify the maximum length DHCP message that the client is able to accept. Use this option in the DHCP configuration file to supply a value when the client does not.

Note! Use this option with caution. Make sure that the client can accept a message of the specified size.

option dhcp-parameter-request-list uint8[,uint8...];

Use this option to request that the server return certain options. Use this option in the DHCP configuration file to override the client's list, or to supply a list when the client does not. The value is a list of valid DHCP option codes as listed in RFC 2132.

option dhcp-server-identifier ip-address;

Use this option to identify the value sent in the DHCP Server Identifier option. The value must be an IP address for the DHCP server, and must be reachable by all clients it is sent to.

It is recommended to NOT use the dhcp-server-identifier option. The only reason to use it is to force a value other than the default value to be sent on occasions where the default value would be incorrect. The default value is the first IP address associated with the physical network interface on which the request arrived. The usual case where the dhcp-server-identifier option needs to be sent is when a physical interface has more than one IP address, and the one being sent by default is not appropriate for some or all clients served by that interface.

option domain-name-servers ip-address [, ip-address ...];

Use this option to list Domain Name System (STD 12, RFC 1035) name servers in order of preference.

option domain-name string;

Use this option to identify the domain name the client should use when resolving hostnames via the Domain Name System.

option extensions-path string;

Use this option to indicate the path-name of a file the client should load containing more options.

option finger-server ip-address [, ip-address ...];

Use this option to list the Finger servers in order of preference.

option font-servers ip-address [, ip-address ...];

Use this option to list X Window System Font servers in order of preference.

option host-name string;

Use this option to name the client. The name may or may not be qualified with the local domain name. It is preferable to use the domain-name option to specify the domain name. See RFC 1035 for character set restrictions.

The host-name option is also used to specify a template for hostname generation. See the Host Name Generation section.

option ieee802-3-encapsulation flag;

If the interface is an Ethernet, use this option to indicate whether the client uses Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation.OFF means use RFC 894 encapsulation.ON means use RFC 1042 encapsulation.

option ien116-name-servers ip-address [, ip-address ...];

Use this option to list IEN 116 name servers in order of preference.

option impress-servers ip-address [, ip-address ...];

Use this option to list Imagen Impress servers in order of preference.

option interface-mtu uint16;

Use this option to identify what MTU value to use on this interface. The minimum legal value is 68.

option ip-forwarding flag;

Use this option to indicate if the client should configure its IP layer for packet forwarding.

  • ON means disable forwarding.
  • OFF means enable forwarding.

option irc-server ip-address [, ip-address ...];

Use this option to list the IRC servers in order of preference.

option log-servers ip-address [, ip-address ...];

Use this option to list MIT-LCS UDP log servers in order of preference.

option lpr-servers ip-address [, ip-address ...];

Use this option to list RFC 1179 line printer servers in order of preference.

option mask-supplier flag;

Use this option to indicate whether or not the client should respond to subnet mask requests using ICMP.

  • ON means do not respond to subnet mask requests.
  • OFF means respond to subnet mask requests.

option max-dgram-reassembly uint16;

Use this option to indicate the maximum size datagram the client should be prepared to reassemble. The minimum legal value is 576.

option merit-dump string;

Use this option to indicate the path-name of a file to which the client’s core image should be dumped in the event of a client crash. The path is formatted as a character string using the NVT ASCII character set.

option mobile-ip-home-agent ip-address [, ip-address ...];

Use this option to list mobile IP home agents in order of preference. Usually there will be only one agent.

option nds-context data-string;

Use this option to identify the initial NDS context the client should use.

option nds-servers ip-address [, ip-address ...];

Use this option to list Novell Directory Services servers in order of preference.

option nds-tree-name data-string;

Use this option to name the NDS tree the client will be contacting.

option netbios-dd-server ip-address [, ip-address ...];

Use this option to list RFC 1001/1002 NetBIOS Datagram Distribution servers in order of preference.

option netbios-name-servers ip-address [, ip-address ...];

Use this option to list RFC 1001/1002 NetBIOS Name Server name servers in order of preference. NetBIOS Name Service is currently more commonly referred to as WINS. WINS servers can be specified using the netbios-name-servers option.

option netbios-node-type uint8;

Use this option to configure configurable NetBIOS over TCP/IP clients as described in RFC 1001/1002. The value is a single octet identifying the client type. Possible node types are

  • 1 B-node: Broadcast--No WINS
  • 2 P-node: Peer--WINS only
  • 4 M-node: Mixed--Broadcast, then WINS
  • 8 H-node: Hybrid--WINS, then Broadcast

option netbios-scope string;

Use this option to specify the NetBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for character-set restrictions.

option nis-domain string;

Use this option to specify the client’s NIS (Sun Network Information Services) domain. Use the NVT ASCII character set to define the domain character string.

option nis-servers ip-address [, ip-address ...];

Use this option to list NIS servers in order of preference.

option nisplus-domain string;

Use this option to specify the client's NIS+ domain. Use the NVT ASCII character set to define the domain character string.

option nisplus-servers ip-address [, ip-address ...];

Use this option to list NIS+ servers in order of preference.

option non-local-source-routing flag;

Use this option to indicate if the client should configure its IP layer to allow forwarding of datagrams with non-local source routes.

  • ON means disable forwarding.
  • OFF means enable forwarding.

option nntp-server ip-address [, ip-address ...];

Use this option to list NNTP servers in order of preference.

option ntp-servers ip-address [, ip-address ...];

Use this option to list NTP (RFC 1035) servers in order of preference.

option option-nnn data-string;

Use this option to identify any DHCP option not listed here. nnn is the number of the option.

option path-mtu-aging-timeout uint32;

Use this option to specify the timeout to use (in seconds) when aging Path MTU values that were discovered by the mechanism defined in RFC 1191.

option path-mtu-plateau-table uint16 [, uint16 ...];

Use this option to specify a table of MTU sizes to use when performing Path MTU Discovery as defined in RFC 1191. The table is a list of 16-bit unsigned integers. You must list them in order from smallest to largest. The minimum MTU value cannot be smaller than 68.

option perform-mask-discovery flag;

Use this option to indicate whether or not the client should perform subnet mask discovery using ICMP.

  • ON means do not perform mask discovery.
  • OFF means perform mask discovery.

option policy-filter ip-address ip-address [, ip-address ip-address ...];

Use this option to indicate the policy filters for non-local source routing. The filters consist of IP addresses and masks that indicate which destination/mask pairs to use when filtering incoming source routes.

The client should discard any source routed datagram whose next-hop address does not match one of the filters. See STD 3 (RFC 1122) for more information.

option pop-server ip-address [, ip-address ...];

Use this option to list POP3 servers in order of preference.

option resource-location-servers ip-address [, ip-address ...];

Use this option to list RFC 887 Resource Location servers in order of preference.

option root-path string;

Use this option to specify the path-name that contains the client’s root disk. The path is formatted using the NVT ASCII character set.

option router-discovery flag;

Use this option to indicate whether or not the client should solicit routers using the Router Discovery mechanism defined in RFC 1256.

  • ON means do not perform router discovery.
  • OFF means perform router discovery.

option routers ip-address [, ip-address ...];

Use this option to list IP addresses for routers in order of preference.

option router-solicitation-address ip-address;

Use this option to identify the address where the client transmits router solicitation requests.

option smtp-server ip-address [, ip-address ...];

Use this option to list SMTP servers in order of preference.

option static-routes ip-address ip-address [, ip-address ip-address ...];

Use this option to specify a list of static routes that the client should install in its routing cache. If there are multiple routes to the same destination, you should list them in descending order of priority.

The routes are made up of IP address pairs. The first address is the destination address; the second address is the router for the destination.

The default route (0.0.0.0) is an illegal destination for a static route. Use the routers option to specify the default route.

option streettalk-directory-assistance-server ip-address [, ip-address ...];

Use this option to list the StreetTalk Directory Assistance (STDA) servers in order of preference.

option streettalk-server ip-address [, ip-address ...];

Use this option to list the StreetTalk servers in order of preference.

option subnet-mask ip-address;

Use this option indicate the client’s subnet mask as per RFC 950. If no subnet mask option is in scope, the DHCP server uses the subnet mask from the subnet declaration on which the address is being assigned. If a subnet mask option is in scope for the address being assigned, it overrides the subnet mask specified in the subnet declaration.

option swap-server ip-address;

Use this option to identify the IP address of the client’s swap server.

option tcp-keepalive-garbage flag;

Use this option to indicate whether the client sends TCP keepalive messages with an octet of garbage for compatibility with older implementations.

  • ON means do not send a garbage octet.
  • OFF means send a garbage octet.

option tcp-keepalive-interval uint32;

Use this option to indicate the interval (in seconds) the client TCP waits before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer.0 (zero) means do not generate keepalive messages unless requested by an application.

option tftp-server-name string;

Use this option to identify a TFTP server. If this option is supported by the client, it should have the same effect as the server-name declaration. BOOTP clients are unlikely to support this option. Some DHCP clients support it; others require it.

option time-offset int32;

Use this option to specify the offset of the client’s subnet (in seconds) from Coordinated Universal Time (UTC). Use negative numbers for West of UTC and positive numbers for East of UTC.

option time-servers ip-address [, ip-address ...];

Use this option to list RFC 868 time servers in order of preference.

option trailer-encapsulation flag;

Use this option to indicate if the client negotiates the use of trailers (RFC 893) when using the ARP protocol.ON means do not use trailers.OFF means use trailers.

option vendor-encapsulated-options data-string;

Use this option to specify vendor specific information.

option www-server ip-address [, ip-address ...];

Use this option to list WWW servers in order of preference.

option x-display-manager ip-address [, ip-address ...];

Use this option to list the systems running X Window System Display Manager in order of preference.

DHCP Lease Format

The DHCP server keeps a persistent database of leases it has assigned. This database is a free-form ASCII file containing a series of lease declarations. Every time a lease is acquired, renewed, or released, its new value is recorded at the end of the lease file. So, if more than one declaration appears for a given lease, the last one in the file is the current one.

Currently, the only declaration that is used in the dhcpd.leases file is the lease declaration. 

lease ip-address {statements...}

Each lease declaration includes the client’s leased IP address. The statements within the braces define the duration of the lease and to whom it is assigned.

Table 2-3 describes the statements the DHCP server puts into a lease file.

See Table 2-8 for a list of DHCP Safe-failover related lease file statements.

Table 2-3 DHCP Lease File Statements
Lease Statement Description

abandoned;

Records that the DHCP server saw the IP address in use on the network when it was thought to be free. The DHCP server detects active addresses with ping tests or "DHCP decline" messages from DHCP clients.

client-hostname "hostname";

Records the hostname if the client sends a hostname using the hostname option.

domain-name "domain-name";

Specifies the DNS domain name sent to the client (if any).

dynamic-bootp;

Indicates the address was leased to a BOOTP client.

ends date;

Records the end time of a lease.

Lease dates are specified by the DHCP server as follows:

W YYYY/MM/DD HH:MM:SS

W is the day of the week, from zero (Sunday) to six (Saturday).
YYYY is the year, including the century.
MM is the number of the month, from 01 to 12.
DD is the day of the month, counting from 01.
HH is the hour, from 00 to 23.
MM is the minute, from 00 to 59.
SS is the second, from 00 to 59.
The time is always in Greenwich Mean Time, not local time.

FQDN "fully-qualified-domain-name";

Specifies the fully qualified domain name used by the DHCP server to perform the dynamic DNS update for the lease (if any).

hardware hardware-type mac-address;

Specifies the hardware type and the MAC address as a series of hexadecimal octets, separated by colons.

hostname "hostname";

Records the hostname if the DHCP server looks up the hostname in DNS. This happens only if the parameter get-lease-hostnames was set.

starts date;

Records the start time of a lease.

uid client-identifier;

Records the client identifier as a series of hexadecimal octets, regardless of whether the client specifies an ASCII string or uses the hardware type/MAC address format. If the client used a client identifier to acquire its address, the client identifier is recorded using the uid statement.

Working with DHCP Leases

The DHCP server requires that a lease database be present before it will start. Before starting the DHCP server for the first time, make sure there is a TCPWARE:DHCPD.LEASES file. If it doesn’t exist, create an empty one.

In order to prevent the lease database from growing without bound, the file is rewritten from time to time. First, a temporary lease database is created and all known leases are dumped to it. Then, the old lease database is renamed TCPWARE:DHCPD.LEASES_OLD. Finally, the newly written lease database is moved into place.

Note! Be aware of the following situation: If the DHCP server process is stopped or the system crashes after the old lease database has been renamed but before the new lease database has been moved into place, the TCPWARE:DHCPD.LEASES file is deleted. The DHCP server will not start. Do not create a new lease file when this happens. If you do, you will lose all your old bindings. Instead, rename TCPWARE:DHCPD.LEASES_OLD to TCPWARE:DHCPD.LEASES, restoring the old, valid lease file, and then start the DHCP server. This guarantees that a valid lease file will be restored.

Abandoned Leases

Abandoned leases are reclaimed automatically. When a client asks for a new address, and the server finds that there are no addresses available, it looks for any abandoned leases. The server allocates the oldest abandoned lease. The standard procedures for checking for lease address conflicts are still followed, so if the abandoned lease's IP address is still in use, it is reabandoned.

If a client requests an abandoned address, the server assumes that the address was abandoned because the lease file was corrupted, and that the client is the machine that responded when the lease was pinged, causing it to be abandoned. In that case, the address is immediately assigned to the requesting client.

Address Lease States in DHCP Dump Files

After obtaining a DHCP dump using NETCU SHOW DHCP/CONFIGURATION, you will see fields in the dump preceded by a pound sign (#). Those fields are values created while the protocol is running and do not directly correlate with the DHCP options listed in Table 2-2. These fields are provided to help you troubleshoot problems. The lease states (denoted by # State= in the dump) are described in Table 2-4.

Table 2-4 DHCP Address Lease States
State Description

Abandoned

The address was seen in use on the network when it was thought to be free. The DHCP server detects active addresses with ping tests or "DHCP decline" messages from DHCP clients.

Bound

The address was assigned in response to a DHCP Request message. If the address lease expires, it remains in "bound" state to help the client regain the same IP address it previously used. The address is actually free. The "(expired)" modifier on the state value indicates this state.

Free

The address has never been bound, and is available in the pool.

Offered

The address has been offered to a client in response to the client's DHCP Discover message, but the client has not asked for the address via a DHCP Request message.

Pinging

The address is in the middle of a ping test.

Static Assignment

The client identifier or hardware address is statically assigned; the binding does not expire.

Reserved forSecondary

Used for DHCP Safe-failover: The address is set aside for the secondary server’s emergency use.

Sample DHCPD.CONF File

Example 2-2 shows a sample DHCPD.CONF file.

Example 2-2 Sample DHCPD.CONF File

#
# TCPWARE:DHCPD.CONF -- sample DHCP configuration file
#

# option definitions common to all supported networks...
option domain-name "fugue.com";
option domain-name-servers toccato.fugue.com;
default-lease-time 43200;
option subnet-mask 255.255.255.0;
option time-offset 18000;
use-host-decl-names on;

# Shared network declaration is used to group subnets which share the same
# physical network together. The name is specified so that the shared 
# network can be referred to in log messages -- 
# it serves no other function.
#
# Note: You must have a subnet declaration for the subnet that the DHCP
# server system is on even if you don’t want any address pool for the same
# subnet (or multiple subnets if the system is multi-homed).

shared-network FUGUE  {

# option definitions common to this shared network.
   option subnet-mask 255.255.255.224;
   default-lease-time 600;
   max-lease-time 7200;

# One of the two IP subnets that share this physical network
#
# Address ranges can be specified for each subnet attached to a shared
# network. Since these subnets share the same physical network, addresses
# are pooled together, and assignments are made without regard to the
# actual subnet. If the optional dynamic-bootp keyword is given in the
# address range declaration, then addresses in that range can be assigned
# either with the DHCP protocol or the BOOTP protocol; otherwise, only
# DHCP clients will have addresses allocated from the address range.
#
# Note that each IP subnet can have its own options specific to that
# subnet. Options that are not specified in the subnet are taken from the
# shared network (if any) and then from the global option list.

subnet 204.254.239.0 netmask 255.255.255.224 {
       range 204.254.239.10 204.254.239.20;
       option broadcast-address 204.254.239.20;
       option routers prelude.fugue.com;
}

# The other subnet that shares this physical network
   subnet 204.254.239.32 netmask 255.255.255.224 {
       range dynamic-bootp 204.254.239.42 204.254.239.52;
       option broadcast-address 204.254.239.31;
       option routers snarg.fugue.com;
}

# Subnets can have no pooled ip addresses.
   subnet 10.10.10.0 netmask 255.255.255.0  {
   }
}

# IP subnets that are alone on their physical wire should be declared by
# themselves. The DHCP server still refers to them as shared networks in
# log messages, but this is simply an artifact of the underlying data
# structure.
#
# Note that options can be specified in the subnet declaration that
# supercede the global options specified earlier.

subnet 192.5.5.0 netmask 255.255.255.224 {
    range 192.5.5.26 192.5.5.30;
    option domain-name-servers bb.home.vix.com, gw.home.vix.com;
    option domain-name "vix.com";
    option routers 192.5.5.1;
    option subnet-mask 255.255.255.224;
    option broadcast-address 192.5.5.31;
    default-lease-time 600;
    max-lease-time 7200;
}

# Hosts that require special configuration options can be listed in host
# statements. If no address is specified, the address will be allocated
# dynamically (if possible), but the host-specific information will still
# come from the host declaration.

host passacaglia {
    hardware ethernet 0:0:c0:5d:bd:95;
    filename "vmunix.passacaglia";
    server-name "toccato.fugue.com";
}

# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only be
# booted with DHCP, unless there is an address range on the subnet to
# which a BOOTP client is connected which has the dynamic-bootp flag set.
host fantasia {
    hardware ethernet 08:00:07:26:c0:a5;
    fixed-address fantasia.fugue.com;
}

# If a DHCP or BOOTP client is mobile and might be connected to a variety
# of networks, more than one fixed address for that host can be specified.
# Hosts can have fixed addresses on some networks, but receive dynamically
# allocated address on other subnets; in order to support this, a host
# declaration for that client must be given which does not have a fixed
# address. If a client should get different parameters depending on what
# subnet it boots on, host declarations for each such network should be
# given. Finally, if a domain name is given for a host’s fixed address and
# that domain name evaluates to more than one address, the address
# corresponding to the network to which the client is attached, if any,
# will be assigned.
host confusia {
    hardware ethernet 02:03:04:05:06:07;
    fixed-address confusia-1.fugue.com, confusia-2.fugue.com;
    filename "vmunix.confusia";
    server-name "toccato.fugue.com";
}

host confusia {
    hardware ethernet 02:03:04:05:06:07;
    fixed-address confusia-3.fugue.com;
    filename "vmunix.confusia";
    server-name "snarg.fugue.com";
}

host confusia {
    hardware ethernet 02:03:04:05:06:07;
    filename "vmunix.confusia";
    server-name "bb.home.vix.com";
}

# Some other examples
host host1 {
    option dhcp-client-identifier "host1";
    fixed-address 10.10.11.101, 10.11.22.101;
}

# Do not allow this one to boot
host host2
    hardware ethernet aa:cc:04:00:33:11;
    deny booting;
}

DHCP Safe-failover Introduction

Since a DHCP server is responsible for the network's IP management, it can also be a potential point of network failure if it becomes unavailable. Using multiple servers with non-overlapping IP address pools is one way to provide limited fault-tolerance. For example: imagine a network with two DHCP servers. Server A has an address range of 100 IP addresses. Server B has a range of 50 different addresses. Both servers have a non-overlapping range of addresses. When a node broadcasts for an address, both servers respond, each offering an address from its own distinct range. Upon receiving both offers, the node chooses one. Typically, the response that reaches the node first is selected. In this case, Server A's. When Server B determines its offer is not needed, it returns the offered address to its own range, allowing it to be offered again.

If one of the servers is down, the other server continues to service the nodes. Now, instead of having two offers, each new node has only one offer, from the remaining server. Nodes that received their lease from the unavailable server attempt to reconnect with it. If the unavailable server does not respond in time, the nodes then attempt to get a new address from a new server. The other server can then offer an address from its own range. So, even though one server is down, the DHCP clients continue to function with the other server. Note that the two DHCP servers operate without any communications or data sharing between them. Each server works as a standalone server.

Since most nodes select the first offer received, having two servers could result in partial use of both IP address pools. Sometimes it is preferable to have a primary DHCP server with the bulk of the IP addresses while the secondary server has a smaller range of IP addresses.

Note! One way to accomplish the above mentioned configuration is to put the secondary server behind a router on a different subnet, while the primary server stays on the same segment as the nodes. This allows the primary server to respond more quickly than the secondary server.

Process Software takes the use of multiple servers to another level by offering DHCP Safe-failover. DHCP Safe-failover allows a secondary DHCP server to back up the primary DHCP server with the addition of taking into account network failure. This strategy insures that clients can reliably log into their corporate network and know they will be able to connect to corporate resources.

In Safe-failover mode both the primary and the backup DHCP servers share a common IP address lease pool. In the event the primary DHCP server fails the backup DHCP server automatically senses the primary server is not operating and automatically assumes complete DHCP operation. When the primary DHCP server becomes operational, it synchronizes with the backup DHCP server and resumes all the responsibilities of the primary DHCP server. All assignments performed by the backup DHCP server while acting as the primary server are transferred to the primary DHCP upon resumption of primary server responsibilities.

Safe-failover adds support for network, not server, failure. In the event the network fails, the secondary server believes the primary server is out of service and begins operation. The secondary server serves leases from a reserved pool shared by the safe-failover partner servers. This reserve pool can be adjusted by the MIS system administrator.

Configuring Safe-failover

To configure your DHCP servers to use Safe-failover, perform the following steps:

1

Choose one system to be the Primary and a second system to be the Secondary.

2

Determine the IP addresses of the Primary and Secondary systems. If a system has more than one IP address, choose one to use for DHCP Safe-failover messages.

3

On the Primary system, create the boot file at TCPWARE:DHCPD.BOOT with the keyword "primary", the primary and secondary IP addresses, and configuration ID. On the primary system, the configuration ID would normally be "dhcpd". See Boot File for DHCP Safe-failover for more information about boot files.

Primary system boot file syntax: 

primary <primary-ip> <secondary-ip> "config-id";

4

Also on the Primary system, if there is no state file (see State File for DHCP Safe-failover), create one at TCPWARE:DHCPD.STATE containing the following line. Note that the name of this file must match the "config-id" parameter in the boot file. 

primary-normal 0;

5

On the Secondary system, create the boot file at TCPWARE:DHCPD.BOOT with the keyword "secondary", the secondary and the primary IP addresses, and configuration ID. On the secondary system, the configuration ID may be "dhcpd" or may be a name that refers to the primary. Either way, the names of the configuration, lease, and state files must match this name.

Secondary system boot file syntax: 

secondary <secondary-ip> <primary-ip> "config-id";

6

Also on the Secondary system, if there is no state file (see State File for DHCP Safe-failover), create one at TCPWARE:DHCPD.STATE containing the following line. Note that the name of this file must match the "config-id" parameter in the boot file. 

backup-normal 0;

7

If you don't already have a configuration file, write a configuration file containing the subnets, shared networks, IP address ranges, hosts, etc, that reflect your network and the hosts you want the DHCP server to service. Include any DHCP Safe-failover parameters as needed (see DHCP Safe-failover Configuration File Statements).

8

Copy the configuration file to the TCPWARE directory on both the Primary and the Secondary systems.

Note! Make sure the name of the configuration file matches the config-id parameter in the boot file for that system.

Preferably, the configuration files on the Primary and the Secondary server systems should be the same. To help ensure that the configuration file is valid for both systems, make sure it contains a subnet statement for every subnet that either the Primary or the Secondary system has a network interface on.

9

Make sure that both the Primary and the Secondary systems have lease files in the TCPWARE directory with the name that matches config-id. If the lease file does not exist, create an empty one.

10

Run the DHCP server on both the Primary and the Secondary systems. The two servers will establish communications with each other and you're in business!

Boot File for Safe-failover

To use Safe-failover, create a boot file at TCPWARE:DHCPD.BOOT. The boot file is used to specify the following for Safe-failover operation:

The format of the boot file is: 

mode [server-IP partner-IP] "config-id";

If the boot file is not present, the server operates with DHCP Safe-failover disabled. It uses tcpware:dhcpd.conf and tcpware:dhcpd.leases for its default configuration and lease files. In this state, the service parameters CONFIGFILE and LEASEFILE may be used to rename or move these files. The server does not use a state file to keep track and remember its state transitions when running in standalone mode (that is, with DHCP Safe-failover disabled). See State File for DHCP Safe-failover for a description of state files.

The following server modes are possible:

Table 2-5 DHCP Safe-failover Server Modes
In this mode The server runs...

Primary

As the primary server, with DHCP Safe-failover functionality enabled. In this mode, the server tries to "shadow" each of its lease transactions to its configured secondary server.

Secondary

As the secondary or Backup server, with DHCP Safe-failover functionality enabled. The server receives lease transaction updates from its configured primary server, and maintains an up-to-the-minute hot backup of the lease database. If the primary server crashes, or is shut down, the secondary server takes over.

Standalone

With DHCP Safe-failover disabled.

The IP address following the server mode is the server address, the next IP address is the secondary or backup server IP address.

The configuration ID is the file name (without the file type) of the configuration, lease, and state files. For example, if the configuration ID is ALPHA, the DHCP server looks for a configuration file named ALPHA.CONF, a lease file named ALPHA.LEASES, and a state file named ALPHA.STATE. 

primary 199.23.24.11 199.23.24.25 "ALPHA";

The example boot file designates the current server as the primary with its own IP address of 199.23.24.11 and the secondary server IP address of 199.23.24.25.

If the mode of operation is "standalone," the IP addresses are not needed. The format is standalone "config-id";

State File for DHCP Safe-failover

The state file is written by the DHCP server when it is running in DHCP Safe-failover mode. The state file saves server state changes so that a server can "remember" its last state if it crashes or is re-started. Alternately, you can use the state file to force the DHCP server to start up in a desired mode (operator override). This feature allows you to switch the server into partner-down mode without a lengthy time-out period, or to start up in recover mode (that is, to force the DHCP server to download the entire lease database from the partner).

The server appends a line to the state file every time its DHCP Safe-failover state changes. The last line in the file is the most current DHCP Safe-failover state.

The state file consists of one or more lines of the following format: 

server_state transaction_count; [date-time;]

In the syntax, server_state is one of the following:

Table 2-6 DHCP Safe-failover Server States
  • failover-disabled
  • startup
  • primary-normal
  • backup-normal
  • primary-comint
  • backup-comint
  • primary-partnerdown
  • backup-partnerdown
  • primary-conflict
  • backup-conflict
  • primary-recover
  • backup-recover

Server-to-server messages are each assigned a monotonously increasing transaction number, which is recorded in the transaction_count field. This is an unsigned 32-bit number.

If the date-time stamp is present, the DHCP server assumes that the state was recorded by the server itself. In this case, the server, upon starting up, calculates the safest state based on the recorded state and the time elapsed. If the date-time stamp is not present, the DHCP server treats the entry as an operator-written override command and starts up in the specified state.

DHCP Safe-failover Lease File Statements

The statements shown in Table 2-7 have been added to the DHCP lease file for DHCP Safe-failover. These are in addition to the DHCP lease file statements listed in Table 2-4.

Table 2-7 DHCP Safe-failover Lease File Statements
Statement Description

acked-sec-interval seconds;

Acknowledged secondary lease interval. For information, see the DHCP Failover internet draft.

acked-sec-interval-start seconds;

The time when the partner was notified of the lease.

active;

This IP address has a current lease.

backup;

This IP address is reserved for use by the secondary (backup) server.

desired-interval seconds;

The length of the desired lease.

expired;

The lease for this IP address has expired.

free;

This IP address is available to be assigned.

released;

The lease for this IP address has been released by the client or by the operator.

reset;

The DHCP server had marked this IP address as abandoned. The operator changed its status to available.

safe-lease;

This is used in the Partner Down state to indicate that the IP address belongs to this server.

transaction-id number;

This is the transaction number that was assigned to this lease when it was queued or sent as an update to the partner server.

update-count n;

For each lease, the server which issues the lease sends an update to its partner server. This statement records the state of that update.

0 means no update is required

1 means that no update has been sent

2+ means 1 or more updates have been sent

DHCP Safe-failover Configuration File Statements

The statements shown in Table 2-8 have been added to the DHCP configuration file for DHCP Safe-failover. These are in addition to the DHCP configuration file statements listed in Table 2-1. All the parameters in Table 2-8 must be placed in the configuration file's global scope, with the exception of the backup-pool-size parameter. It may also be specified within a shared-network or subnet declaration.

Table 2-8 DHCP Safe-failover Configuration File Statements
Statement Description

backup-ack-interval

The number of seconds used as the basis of the DHCP server's logarithmic back-off algorithm used for resending ACK messages to the secondary server. The default is 1 second. 

backup-ack-interval seconds;

backup-pool-size

This is the percentage of the IP address pool set aside for the Secondary server’s emergency use. The DHCP server will reserve no more than 50% of the available addresses. The default is 10%. 

backup-pool-size percent;

com-int-timeout

The number of seconds the server should wait for an expected response from its partner before switching to communication interrupted mode. The default is 600 seconds (10 minutes). 

com-int-timeout seconds;

failover-port

The UDP port the Primary and Secondary servers should use for DHCP Safe-failover messages. The default is 647. 

failover-port port;

mclt

Maximum Client Lead Time: This is the length of lease in seconds to give out on a first time basis, or the client lead time for renewals. See the DHCP Failover internet draft for a more detailed explanation. The default is 3600 seconds (1 hour). 

mclt seconds;

safe-period-timeout

The number of seconds spent in communication interrupted state before automatic switch over to partner-down state. A value of 0 means no automatic switch over. The default is 0 seconds. 

safe-period-timeout seconds;

startup-delay

The number of seconds to wait during startup before the server moves from STARTUP state to the state specified in the state file. The default is 5 seconds. 

startup-delay seconds;

Transitioning to DHCP Safe-failover Partner-Down State

There are three ways that you can transition the DHCP server to Partner Down state, which indicates that its DHCP Safe-failover partner is down.

1

If the parameter safe-period-timeout is specified in the configuration file, the DHCP server transitions to Partner Down state automatically after it has been in Communication Interrupt state for the specified time.

2

You can put the DHCP server into Partner Down state using the following NETCU command: 

$ netcu set dhcp/partnerdown

3

You can edit the DHCP server state file and add a line to the end containing the Partner Down state and transaction number desired. Add either line:

  • primary-partnerdown transaction-number;
  • backup-partnerdown transaction-number;

The next time the DHCP server is restarted, it will be in Partner Down state. You can restart the DHCP server by shutting down the server with the NETCU STOP/DHCP command. NETCP automatically restarts the DHCP server.

Previous Page Page Top TOC Index Next Page