18. Configuring Remote Systems with RARP, BOOTP, and DHCP Server

This chapter explains how to configure MultiNet to supply network configuration data to remote client systems when they boot.

MultiNet provides three services that provide configuration data to remote systems:

· RARP (Reverse Address Resolution Protocol)

· BOOTP (Bootstrap Protocol) (responds only to BOOTP clients)

· DHCP (Dynamic Host Configuration Protocol) (responds to both BOOTP and DHCP clients)

The BOOTP and DHCP servers allow a network administrator to configure various hosts on the network from a single location. In addition to the management of IP addresses, BOOTP and DHCP also provide configuration parameters to clients, such as default gateway, domain name server, and subnet mask.

Choosing a Network Configuration Server

This section presents a brief description of the services and some criteria for deciding which protocol and services to use. The following table lists the advantages and disadvantages of the three protocols:

Service	Advantages and Disadvantages
RARP	Supplies IP addresses only.
BOOTP	Lets you provide vendor-specific configuration data. Works in conjunction with TFTP. Provides static configuration data only.
DHCP	Lets you provide vendor-specific configuration data. Provides both BOOTP and DHCP services. Provides dynamic configuration for mobile computing, but does not solve all problems of mobile computing.

RARP (Reverse Address Resolution Protocol)

RARP’s sole function is to provide IP addresses to hosts that broadcast RARP requests with their hardware addresses.

BOOTP (Bootstrap Protocol)

BOOTP sends IP addresses and other configuration data to hosts that broadcast BOOTP requests. Because some BOOTP clients require more data to boot than can fit in a BOOTP response, BOOTP provides a means for specifying the location of a boot file. The BOOTP client can then load the file using TFTP (Trivial File Transfer Protocol). Usually, the data in the boot file (such as an X server for an X terminal) is specific to the vendor of the BOOTP client software.

The BOOTP service responds to BOOTP requests only. If you are using the BOOTP-only service, DHCP services are not available. The BOOTP server is provided for backwards compatibility for those sites not wanting to change their configuration.

DHCP (Dynamic Host Configuration Protocol)

DHCP is an extension of the BOOTP protocol. DHCP sends IP addresses and other configuration data to hosts that broadcast DHCP requests. DHCP "leases" an IP address to a remote system for a finite time. DHCP lets you manage IP addresses and configuration data for a "pool" of remote systems, which makes DHCP useful for mobile computers that connect to multiple subnets.

As with BOOTP, DHCP provides a means for specifying the location of a boot file which the DHCP client can load using TFTP. For details on creating a downloadable boot file for a specific type of host, refer to the vendor's documentation.

If you are using the DHCP server, all BOOTP services are available as well. A MultiNet host can have only one of the servers (BOOTP or DHCP) enabled because both use the same port.

Note! Your BOOTP and DHCP configuration files must be located in the default location of MULTINET: in order for an automatic conversion to occur.

Using RARP

RARP (Reverse Address Resolution Protocol) is commonly used by diskless hosts to determine their Internet address. While ARP (Address Resolution Protocol) lets hosts resolve Internet addresses into Ethernet addresses, RARP lets them resolve Ethernet addresses into Internet addresses. Configuring the MultiNet RARP server consists of:

1. Obtaining the data needed by each RARP client (see the Obtaining Data for RARP Clients section).

2. On HP Ethernet interfaces only, enabling RARP packet reception (see the Enabling RARP Packet Reception on HP Ethernet Interface section).

3. Enabling and starting RARP (see the Enabling and Starting RARP Service section).

4. Adding client systems to the RARP configuration file (see the Adding Clients to the RARP Configuration File section).

5. Reloading the RARP configuration (see the Reloading RARP Configuration section).

Note! Because RARP clients send their requests in a link-layer broadcast (Ethernet, for example) and most routers do not forward link-layer broadcasts, make sure the MultiNet system and all its RARP clients are on the same physical network.

Obtaining Data for RARP Clients

Obtain the IP and Ethernet addresses for each client you want to use with RARP. To obtain a client's Ethernet interface address, refer to the interface documentation.

Ethernet addresses are expressed as six hexadecimal numbers (ranging from 0 to ff) separated by colons. IP addresses are expressed in dotted-decimal format.

Enabling RARP Packet Reception on HP Ethernet Interfaces

If your MultiNet system has an HP Ethernet interface, enable RARP packet reception with the MULTINET SET /INTERFACE command. For example, to enable RARP packet reception on the se0 interface:

$ MULTINET SET/INTERFACE/VMS_DEVICE=XQA0:/LINK_LEVEL=ETHERNET/RARP SE0

To automatically enable RARP packet reception when MultiNet starts, make sure to add the /RARP qualifier to the MULTINET SET /INTERFACE command line in the custom initialization command procedure for the interface, as described in Chapter 11.

Enabling and Starting RARP Service

To enable RARP, use SERVER-CONFIG:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE RARP
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
$

Once you have enabled RARP, start it by restarting the MultiNet Master Server:

$ @MULTINET:START_SERVER

Adding Clients to the RARP Configuration File

The MultiNet RARP server uses Ethernet-to-IP address translations from the MULTINET:RARP.CONFIGURATION file. Each single-line entry in RARP.CONFIGURATION contains an Ethernet address and the corresponding Internet address.

The following RARP.CONFIGURATION sample shows the IP addresses assigned to the hosts with Ethernet addresses aa:00:04:00:45:12 and 00:0c:00:17:12:67.

#
#   This is a sample RARP database. It provides the mapping between
#   ethernet addresses and IP addresses as used by RARP.
#
# ethernet address      ip address
# ----------------      ----------
aa:00:04:00:45:12     192.0.0.1
00:0c:00:17:12:67     192.0.0.2

Reloading RARP Configuration

After modifying the MULTINET:RARP.CONFIGURATION file, reload the RARP configuration with the following command:

$ MULTINET NETCONTROL RARP RELOAD

Using BOOTP

The MultiNet BOOTP (Bootstrap Protocol) service lets your OpenVMS system help diskless hosts and other network devices establish network connectivity. The remote system broadcasts a BOOTP request over the network with its Ethernet address. The BOOTP server looks up the host's address in a configuration file (MULTINET:BOOTP-SERVER.CONFIGURATION) and responds with the host's IP address, subnet mask, gateway address, initial load file, and any other data needed by the client. Using this information, the client can boot from the network.

Starting with MultiNet V3.5, MultiNet includes two BOOTP servers: An older server provided for backwards compatibility for those sites not wanting to change their configuration, and a newer DHCP/BOOTP server that provides features not present in the older, BOOTP-only server.

For details on BOOTP see RFC-951, "Bootstrap Protocol," and RFC-1084, "BOOTP Vendor Information Extensions."

Configuring the BOOTP server involves:

1. Obtaining the data required by each BOOTP client (see Obtaining Data for BOOTP Clients).

2. Enabling and starting BOOTP (see Enabling and Starting BOOTP).

3. Modifying the BOOTP configuration file (see Modifying the BOOTP Configuration File).

4. Reloading the BOOTP configuration (see Reloading the BOOTP Configuration).

5. Disabling debug messages, if desired (see Disabling BOOTP OPCOM Messages).

Note! While BOOTP is often used with clients and servers on the same network, they can be on different physical networks. Most routers can be configured to forward BOOTP requests; refer to your router documentation.

Obtaining Data for BOOTP Clients

Make a list of the configuration parameters (known as BOOTP options) required by the devices you want to configure using BOOTP. The table below lists BOOTP options.

Because some network devices require large amounts of information or vendor-specific configuration at boot time, BOOTP lets you specify the path names of additional configuration files the client can download from TFTP servers. For details on creating downloadable configuration files for a specific host, refer to the vendor's documentation.

Note! If you are running DNS, make sure you use the same IP address and host name data used by your primary site's DNS servers. If you are using host tables instead of DNS, make sure you use the same IP address and host name data listed in MULTINET:HOSTS.LOCAL.

Enabling and Starting BOOTP

You can enable BOOTP with SERVER-CONFIG:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE BOOTP
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
$

Note! BOOTP cannot run while DHCP is enabled because both services use the same port. You can use SERVER-CONFIG to disable DHCP.

After enabling BOOTP, start it by restarting the MultiNet Master Server:

$ @MULTINET:START_SERVER

Modifying the BOOTP Configuration File

MultiNet supplies a MULTINET:BOOTP-SERVER.CONFIGURATION file that contains comments and a number of examples to help you enter information for your hosts.

BOOTP Options for the BOOTP Server

This table describes the options you can define for each host and an example of each option.

Field	Description		Example
bf	File downloaded by TFTP to the client at boot time. This file is supplied by the device vendor. The file must exist and be world-readable. If the file is not found, a null file specification is returned.	bf="mom$load:xncd16_lt"
bs	Bootfile size. If the value is the string "auto" or no value is given, the server automatically determines the size. Otherwise, the specified value is passed verbatim. The size is expressed in 512-byte blocks.	bs=auto or bs=24
cs	Space-separated list of "quote of the day" server IP addresses. The cookie (as in "fortune cookie") server is described in RFC-865.	cs=192.41.228.92
ds	Space-separated list of domain name server IP addresses	ds=192.41.228.65
gw	IP address of the default gateway	gw=128.2.13.1
ha	Hardware address of the client. The format of the hardware address depends on the hardware type (ht). Specify the hardware type (ht) before the hardware address (ha).	ha=00DD00C88900
hd	Home directory for the boot files	hd="sys$sysroot: [bootp-boot files]"
hn	Flag requesting the host name to be sent to the client. When an entry contains this tag, the contents of the name field (the initial string of characters on each record up to, but not including the first colon) are sent to the client. If the name field is greater than 58 characters, only the host field (up to the first period) is sent. If the host field by itself does not fit, no value is sent.	hn
ht	Hardware address type. The hardware type must be interpreted before the hardware address (ha). Valid values are the hardware type, expressed as a decimal number as defined by the RFCs or a text string that maps to the hardware type number: ethernet 1 ieee803 6 chaos 5 ethernet3 2 tr 6 arcnet 7 ether 1 token-ring 6 ax.25 3 ether3 2 pronet 4	ht=ethernet, ht=6
im	Space-separated list of Imagen-type "Impress" server IP addresses	im=192.168.228.92 192.168.228.93
ip	IP address of the host	ip=192.168.228.82
lg	Space-separated list of MIT-LCS UDP log server IP addresses	lg=192.168.228.42
lp	Space-separated list of LPR server IP addresses	lp=192.168.228.37
ns	Space-separated list of IEN-116 name server IP addresses	ns=192.168.228.77
rl	Space-separated list of RLP (Resource Location Protocol) server IP addresses	rl=192.168.228.19
sa	IP address of a boot server	sa=192.168.228.222
sm	Subnetwork mask	sm=255.255.255.192
tc	Template host label. Use the tc field to "include" information from another entry in the configuration file. You may create a common entry for a group of hosts, such as a specific vendor's X terminals. Use the tc field to combine information specific to each model. Information in the current entry overrides information included by the tc field. A tc entry may also "include" another entry with a tc field of its own.	tc=global.dummy
td	TFTP directory. Used to reference part of a directory that may be hidden from the client via the TFTP server.	td="TFTP$DIR:"
to	Time offset (in seconds) east of GMT for the client. Error! Reference source not found. lists accepted values. BOOTP uses negative numbers west of GMT and positive numbers east of GMT. See the table below for the time offset values you can specify in this field.	to=25200
ts	Space-separated list of time server IP addresses	ts=192.41.228.77
Tn	"Generic" tag of the type "Tn=value," · n is the number assigned the option. · value is either ASCII data enclosed in quotes or binary data expressed as hexadecimal digits. When expressing binary data that represents short or long values, be sure to check the byte order to compensate for the difference between OpenVMS byte order and network byte order. For values with known tags, the server can convert between the two. For values in generic tags, however, the server cannot tell the difference between a four-byte binary string and an unsigned long value.	T123="Hello World" or T124=FFFE2CEF
vm	"Vendor magic" to send: "auto", "rfc1048", "rfc1084", "cmu", or a dotted-decimal value. Vendor magic is always "rfc1084" when using DHCP. Default: auto.	vm="rfc1048"

This table provides time offset values you can specify in the to field:

Timezone	Time Offset	DST Time Offset	Timezone	Time Offset	DST Time Offset
AST/ADT	-14400	-10800	MET/MET-DST	7200	3600
BST	0	3600	MST/MDT	-25200	-21600
CET/CET-DST	7200	3600	NST/NDT	-12600	-9000
CST/CDT	-21600	-18000	NZST	86400	90000
EET/EET-DST	10800	14400	PST/PDT	-28800	-25200
EST/EDT	-18000	-14400	SST	+28800	none
GMT	0	none	UTC	0	none
HST	-36000	none	WET/WET-DST	3600	7200
JST	32400	none	YST/YDT	-32400	-28800

Guidelines for the BOOTP Configuration File

The following guidelines govern modification of the
MULTINET:BOOTP-SERVER.CONFIGURATION file:

· Edit the configuration file with any text editor.

· Use a pound sign (#) in the first column of the line to designate a comment line. Comment and blank lines are ignored by the server.

· Specify the hardware type (ht) before the hardware address (ha).

· Specify IP addresses in dotted-decimal notation.

Note! If you enter an IP address with leading zeros as part of the address (for example, 192.41.012.011), the octets with leading zeros are interpreted as octal values rather than decimal values.

· For readability, limit each entry to one line when possible. Otherwise, put each field on a separate line.

· Separate entry fields with a colon (:). When lines are continued on another line, separate fields with a colon followed by a backslash. You should start each new line with a tab followed by a colon. Here are examples of the two different entry styles:

ncd16s:\
          :ht=ethernet:\
          :bf="mom$load:xncd16_lt":\
          :gw=192.41.228.71:\
          :sm=255.255.255.192:\
          :ds=192.41.228.65:\
          :to=25200:
tree:tc=ncd16s:ha=0000C0545F24:ip=192.41.228.75:

· Use the tc field as an "include" statement to succinctly provide additional information for an individual device, as shown in the example entries above. The entry called "tree" is for an individual NCD terminal. Including the tc option adds all of the information in the "ncd16s" entry to the "tree" entry.

The tc field lets you create a common entry for a class of hosts (such as a vendor's X terminals) that conveys generic information. Entries that include tc options supply information specific to an individual terminal, such as its IP address.

Information in the individual entry overrides the information included by the tc field.

· When specifying more than one server for the cs, ds, im, lg, lp, ns, rl and ts fields, separate subsequent server values with spaces.

Using a UNIX bootptab File

If you are also running a BOOTP server on a UNIX system, you can use the UNIX system's bootptab configuration file after making the following changes:

· Copy the bootptab file to MULTINET:BOOTP-SERVER.CONFIGURATION.

· Change the syntax of directories and file names to OpenVMS format.

· Do not add names that conflict with existing entries.

Reloading the BOOTP Configuration

After modifying MULTINET:BOOTP-SERVER.CONFIGURATION, reload the BOOTP configuration with the following command:

$ MULTINET NETCONTROL BOOTP RELOAD

Disabling BOOTP OPCOM Messages

After you test your BOOTP configuration, you may want to suppress some of the messages the BOOTP server sends to OPCOM by changing the debug level of the BOOTP server, as shown in this example:

$ MULTINET NETCONTROL BOOTP DEBUG -1

If you want this change to take place each time MultiNet is started, use the SERVER-CONFIG SET PARAMETERS command as follows:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT BOOTP
[The Selected SERVER entry is now BOOTP]
SERVER-CONFIG>SET PARAMETERS
Delete parameter "bootfile MULTINET:BOOTP-SERVER.CONFIGURATION" ? [NO]RETURN
You can now add new parameters for BOOTP. An empty line terminates.
Add Parameter: debug -1
Add Parameter: RETURN
[Service specific parameters for BOOTP changed]
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$

Using DHCP

The MultiNet DHCP (Dynamic Host Configuration Protocol) server lets your OpenVMS system help diskless hosts and other network devices establish network connectivity. The DHCP server provides all of the functions of BOOTP plus dynamic addressing and additional configuration options.

The DHCP server offers a network host a temporary lease of an IP address rather than an ownership of an IP address, such as BOOTP does. The lease identifies the length of time the client can safely use its assigned IP address. The network administrator sets the lease length using parameters in the configuration file. It is recommended that the network administrator assign lease lengths based on the number of network users and the number of available IP addresses the DHCP server can assign. To configure the DHCP server:

1. Obtain the data required by each DHCP client (see Obtaining Data for DHCP Clients).

2. Modify the DHCP configuration file (see Introducing the Configuration File).

3. Enable and start the DHCP server (see Enabling and Starting DHCP).

4. If you modify the configuration file after starting the DHCP server, reload the DHCP server (see Reloading the DHCP Configuration).

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 the diagram below. The process is 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 Error! Reference source not found.) 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 (acknowledgement) 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 acknowledgement 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.

See the DHCP RFCs for more information. DHCP is defined in RFC 2131 and RFC 2132.

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.

Obtaining Data for DHCP Clients

Make a list of the configuration parameters (known as DHCP options) required by the devices you want to configure using DHCP.

Enabling and Starting DHCP

You can enable the DHCP server with SERVER-CONFIG:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE DHCP
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
$

Note! DHCP cannot run while the BOOTP server is enabled because both servers use the same port. Because the DHCP server provides BOOTP service as well, there is no need to run the BOOTP service.

After you have enabled DHCP, start the DHCP server by restarting the MultiNet Master Server. If the DHCP server is already running, shut it down first.

$ MULTINET NETCONTROL DHCP SHUTDOWN
$ @MULTINET:START_SERVER

Checking the DHCP Configuration

After modifying the configuration file, it is good practice to verify the syntax by running the DHCP server interactively specifying the -t flag, as follows:

$ dhcpd :== $multinet:dhcpd.exe
$ dhcpd -t [-cf <config-file>]

You can test both the configuration file and the lease file using the -T flag:

$ dhcpd “-T” [-cf <config-file>] [-lf <lease-file>]

The -t flag causes the DHCP server to run just far enough to read and parse the configuration file. The DHCP server displays a copyright notice as well as a message for each syntax error encountered. If the DHCP server displays only the copyright notice, the configuration file has no syntax errors.

The -T flag causes the DHCP server to run just far enough to read and parse the configuration and lease files.

DHCPD can be made to use an alternate configuration file with the -cf flag, or an alternate lease file with the -lf flag. If you do not specify the -cf flag, the DHCP server reads the default configuration file MULTINET:DHCPD.CONF. If you do not specify the -lf flag, the DHCP server reads the default lease file MULTINET:DHCPD.LEASES. Because of the importance of using the same lease database at all times when running DHCPD in production, these flags should be used only for testing lease files or database files in a non-production environment.

Reloading the DHCP Configuration

If you modify MULTINET:DHCPD.CONF after starting the DHCP server, restart DHCP with the following command so the DHCP server rereads DHCPD.CONF:

$ MULTINET NETCONTROL DHCP RESTART

DHCP Conversion Tool

The DHCP_CONVERSION_TOOL assists in moving from the DHCP server in MultiNet V4.1 and earlier to the DHCP server in MultiNet V5.2 and later. This tool converts the configuration files and state file from the 4.1 DHCP server to the format of the configuration and lease files of the 5.5 DHCP server. It is run automatically by the command procedure that starts the MultiNet Master Server, MULTINET:START_SERVER.COM. However, it is recommended that customers run the conversion tool and double check the output ahead of time.

The conversion tool reads the old BOOTP and DHCP configuration files and writes out a configuration file in the new format, representing a merging of the two old configuration files, with DHCP configuration information being preferred. All information from the old configuration files is in the new file. Information that was duplicated or that does not have an equivalent in the new configuration file is represented with comment lines.

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

The conversion tool preserves the old configuration and state files where they were. The network administrator can use them to validate the new configuration and lease files.

The conversion tool may also be run directly. The names of the input and output files may be specified on the command line. If they are not specified, the tool will prompt for them. Enter “NONE” for the file name if you do not have the input file. For example, if you do not have a BOOTP configuration file:

$ dhcpconvert :== $multinet:dhcp_conversion_tool.exe
$ dhcpconvert dhcp-server.configuration NONE -
_$ dhcp-state.dat dhcpd.conf dhcpd.leases

Enter “?” as the sole parameter to get a help message. The default file names for the five files are:

MULTINET:DHCP-SERVER.CONFIGURATION	the old DHCP configuration file
MULTINET:BOOTP-SERVER.CONFIGURATION	the old BOOTP configuration file
MULTINET:DHCPD.CONF	the new DHCP configuration file
MULTINET:DHCP-STATE.DAT	the old DHCP state file containing the lease status
MULTINET:DHCPD.LEASES	the new DHCP lease file

The conversion tool may produce large configuration files. To reduce the size of these configuration files, set the following logical name before running the conversion tool:

$ define MULTINET_DHCP_CONV_BRIEF YES

Introducing the Configuration File

MultiNet supplies a MULTINET:DHCPD.CONF file that contains comments and a number of examples to help you enter information for your hosts. You can edit the configuration file with any text editor. Add or remove entries as needed.

The dhcpd.conf file is a free-form ASCII text file. The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insensitive. 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 the sample DHCP.CONF file at the end of this chapter.

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

Parameter statements always say one of the following:

· How to do something (e.g., how long a lease to offer).

· Whether to do something (e.g., should the DHCP server provide addresses to unknown clients).

· What parameters to provide to the client (e.g., use gateway 220.177.244.7).

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, something like:

option routers 204.254.239.1;

Note! The address here is specified numerically. This is not required. If you have a different domain name for each interface on your router, it is perfectly appropriate to use the domain name for that interface instead of the numeric address. However, there may be only one domain name for all of 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 (e.g., 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:

· Hostname option.

· Name of a file to upload (the filename parameter).

· Address of the server from which to upload the file (the next-server parameter).

In general, any parameter can appear anywhere 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:

· Describe the topology of the network.

· Describe clients on the network.

· Provide addresses that can be assigned to clients.

· Apply a group of parameters to a group of declarations.

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 will be dynamically allocated on that subnet.

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

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

· For clients with statically assigned addresses, or for installations where only known clients will be served, each client must have a host declaration.

· If parameters are to be applied to a group of declarations that are not related strictly on a per subnet, class, or pool 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 these two networks in a shared-network declaration.

Some sites may have departments that have clients on more than one subnet, but it may be desirable 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.

· For clients declared explicitly with host declarations, enclose these declarations in a group declaration using the parameters that are common to that department.

· For clients with dynamically assigned addresses, one way to group parameter assignments is by network topology. Alternately, host declarations can provide parameters and if they have no fixed-address parameter, the clients get an address dynamically assigned. See the host declarations example below.

· Clients can be grouped into classes and assigned IP addresses from specific pools.

When a client is to be booted, its boot parameters are determined by consulting the following scopes in this order:

1. Client’s host declaration (if any).

2. Group declaration (if any) that enclosed the host declaration.

3. Subclass declaration for the subclass the client belongs to (if any).

4. Class declaration for the class the client belongs to (if any).

5. Pool declaration that the assigned IP address comes from (if any).

6. Subnet declaration for the subnet on which the client is booting.

7. Shared-network declaration (if any) containing that subnet.

8. 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.

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. One way to do this would be to have host declarations for each server and group them by model:

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; }
}

Address Allocation

Address allocation is done when a client is in the INIT state and has sent a DHCPDISCOVER message. When the DHCP server is looking for an IP address to allocate to a client, it checks first

· if the client has an active lease on an IP address, or

· if the client has an expired lease on an IP address that has not been reassigned.

It then follows these rules:

· If a lease was found but the client is not permitted to use it, then the lease is freed (if it was not expired already).

· If no lease is found or a lease was found and the client is not permitted to use the address, then the server looks for an address that is not in use and that the client is permitted to have among the list of address pools on the client’s subnet.

· If no addresses are found that can be assigned to the client, then no response is sent to the client.

· If an address is found that the client is permitted to have, then the address is allocated to the client.

Note! IP addresses that have never been assigned are chosen over those that have previously been assigned to other clients.

If the client thinks it has a valid lease and sends a DHCPREQUEST to initiate or renew that lease, the server has three choices. It can

· Ignore the DHCPREQUEST.

· Send a DHCPNAK, telling the client to stop using the address.

· Send a DHCPACK, telling the client to use the address.

If the server finds the requested address and that address is available to the client, the server sends a DHCPACK.

If the address is no longer available or the client is not permitted to have it, the server sends a DHCPNAK.

If the server knows nothing about the address, the server remains silent. However, if the address is incorrect for the network segment to which the client is attached and the server is authoritative for that segment, the server sends a DHCPNAK.

Address Pools

Pool declarations let you have different allocation policies for different address allocation pools. A client may be denied access to one pool, but allowed access to another pool on the same network segment.

A pool declaration is used to specify how a group of addresses should be treated differently than another group of addresses, even if they are on the same network segment or subnet.

For example, you can provide a large set of addresses assigned to DHCP clients that are known to your DHCP server, while at the same time providing a small set of addresses that are available for unknown clients. If you have a firewall, you can arrange for addresses from one pool to have access to the Internet, while addresses in another pool do not have access to the Internet. The following example illustrates how you could set up a pair of pool declarations.

subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.254;

# Unknown clients get this pool.
pool {
    option domain-name-servers bogus.example.com;
    max-lease-time 300;
    range 10.0.0.200 10.0.0.253;
    allow unknown clients;
}

# Known clients get this pool.
pool {
    option domain-name-servers ns1.example.com, ns2.example.com;
    max-lease-time 28800;
    range 10.0.0.5 10.0.0.199;
    deny unknown clients;
}
}

You can also set up entirely different subnets for known and unknown clients. This is possible because address pools exist at the level of shared networks, so address ranges within pool declarations can be on different subnets, as long as they are on the same shared network.

Pool Permit Lists

The above example shows that address pools can have permit lists. A permit list controls which clients are allowed access to the address pool and which clients are not allowed access. Each entry in a permit list is introduced with the allow or deny keyword. The following table describes the four possibilities for eligibility to addresses from the address pool.

If a pool has...	Then...
a permit list	only those clients that match specific entries on the permit list are eligible for addresses from the pool.
a deny list	only those clients that do not match any entries on the deny list are eligible for addresses from the pool.
both a permit list and a deny list	only clients that match the permit list and do not match the deny list are eligible for addresses from the pool.
neither a permit list nor a deny list	all clients are eligible for addresses from the pool.

Range declarations that appear outside of pool declarations in the same shared-network are grouped into two pools: one which allows all clients for range statements with the dynamic-bootp keyword and one which denies dynamic bootp clients for range statements without the dynamic-bootp keyword.

As described in the Address Allocation section, the DHCP server checks each IP address to see if the client is permitted to use it, in response to both DHCPDISCOVER and DHCPREQUEST messages. The DHCP server checks both the address pool permit lists and the relevant in-scope allow and deny statements.

See the table of DHCP statements for the recognized allow and deny statements. They can be used to permit or refuse access to known or unknown clients, members of a class, dynamic bootp clients, or all clients.

Note! The DHCP v2.0 (MultiNet v4.2) style allow and deny statements (e.g., allow/deny unknown-clients) and range statement dynamic-bootp keyword do not mix well with pool permit lists. A v2.0-style deny statement overrides the pool permit lists, and the dynamic-bootp keyword is ignored inside of pools. Note also that the default for dynamic-bootp changes from deny to allow when pools are used.

Client Classing

You can separate clients into classes, treating each client differently depending on what class it is in. To separate clients into classes, use conditional statements (see the Conditional Behavior section) or a match statement within a class declaration. You can specify a limit on the total number of clients within a particular class or subclass that may hold leases at one time using the lease limit statement. You can specify automatic subclassing based on the contents of the client packet using the spawn with statement.

To add clients to classes based on conditional evaluation, write a conditional statement to match the clients you want in the class. Then, put an add statement in the conditional's list of statements. For example, to identify requests coming from Microsoft Windows RAS servers:

if substring (option dhcp-client-identifier, 1, 3) = "RAS" {
add "ras-clients";
}

An equivalent way to do this is to specify the conditional expression as a matching expression in the class statement. For example:

class "ras-clients" {
match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
}

Note! Whether you use matching expressions or add statements (or both) to classify clients, you must write a class declaration for any class that you use.

If you want no match statement and no in-scope statements for a class, the declaration looks like this, for example:

class "ras-clients" {
}

Important! The add statement adds the client to the class after the address assignment has been completed. This means the client will not be affected by pool permits related to that class if the client is a member of a class due to an add statement.

Subclasses

In addition to classes, you can declare subclasses. A subclass is a class having the same name as a regular class but with a specific submatch expression that is hashed for quick matching. It is quicker to find five subclasses within one class than it is to find five classes with match expressions. The following example illustrates how to code for subclasses:

class "allocation-class-1" {
match hardware;
}

class "allocation-class-2" {
match hardware;
}

subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;

subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
    allow members of "allocation-class-1";
    range 10.0.0.11 10.0.0.50;
}
pool {
    allow members of "allocation-class-2";
    range 10.0.0.51 10.0.0.100;
}
}

The data following the class name in the subclass declaration is a constant value used in matching the match expression for the class. During class matching, the server evaluates the match expression and looks up the result in the hash table. If a match if found, the client is considered a member of both the class and the subclass.

You can specify subclasses with or without scope (i.e., statements). In the above example, the sole purpose of the subclass is to allow some clients access to one address pool, while other clients are given access to the other pool. Thus, these subclasses are declared without any statements (scope). If you wanted to define different parameter values for some clients, you would declare those subclasses with scopes.

For example: if you had a single client needing some configuration parameters, while most did not, you might write the following subclass declaration for that client:

subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}

In the previous examples, subclassing is being used as a way to control address allocation on a per-client basis. However, it is possible to use subclassing in ways that are not specific to clients. For example, to use the value of the vendor-class-identifier option to determine what values to send in the vendor-encapsulated-options option. See the Vendor Encapsulated Options section.

Note! If you are using match hardware, the hardware address is preceded by the hardware type. In this example, the “1:” indicates Ethernet.

Per-Class Limits on Dynamic Address Allocation

The number of clients in a class that can be assigned leases can be limited. This limiting makes it difficult for a new client in a class to get an address. Once a class has reached its limit, the only way a new client in that class can get a lease is for an existing client to relinquish its lease, either by

· letting it expire, or

· sending a DHCPRELEASE packet.

The following example illustrates how to specify classes with lease limits.

class "limited-1" {
lease limit 4;
}

This produces a class in which a maximum of four members may hold leases at one time.

If you want to provide clients at a particular site with more than one IP address, but do not want to provide these clients with their own subnet, nor give them an unlimited number of IP addresses from the network segment to which they are connected, you can create a spawning class and use lease limits. A spawning class is a class that produces subclasses automatically based on what the client sends.

Many cable modem head-end systems can be configured to add a Relay Agent Information option to DHCP packets when relaying them to the DHCP server. These systems typically add a circuit ID or remote ID option that uniquely identifies the customer site. The following example illustrates how to write a class declaration to take advantage of these relay agent options to create lease limited classes on the fly:

class "customer" {
match if exists agent.circuit-id;
spawn with option agent.circuit-id;
lease limit 4;
}

With this class declaration, whenever a request comes in from a customer site, the circuit ID option is checked against the class's hash table.

· If a subclass matches the circuit ID, the client is classified in that subclass.

· If no subclass matches the circuit ID, a new subclass is created and logged in the dhcpd.leases file and the client is classified in the new subclass.

Once a client is classified, it is treated according to the rules of the class; as in the example above, being subjected to the per-site limit of four leases.

Note! The use of the subclass spawning mechanism is not restricted to relay agent options. This particular example is given only because it is a straightforward one.

Conditional Behavior

The DHCP server can be configured to perform conditional behavior depending on the packets it receives.

Conditional behavior is specified using the if statement and the else or elsif statements. A conditional statement can appear anywhere that a regular statement can appear, and can enclose one or more such statements. The following is an example of a conditional statement.

if option dhcp-user-class = "accounting" {
max-lease-time 17600;
option domain-name "accounting.example.org";
option domain-name-servers ns1.accounting.example.org,
                                         ns2.accounting.example.org;
} elsif option dhcp-user-class = "engineering" {
max-lease-time 17600;
option domain-name "engineering.example.org";
option domain-name-servers ns1.engineering.example.org,
                                         ns2.engineering.example.org;
} else {
max-lease-time 600;
option domain-name "misc.example.org";
option domain-name-servers ns1.misc.example.org,
                                         ns2.misc.example.org;
}

Both the if statement and the elsif continuation statement take expressions that, when evaluated, produce a boolean result. See the Expressions section for more information.

· If the expression evaluates to true, then the statements enclosed in braces following the if statement are executed. All subsequent elsif and else clauses are skipped.

· If the expression evaluates to false, then the statements enclosed in braces following the if statement are not executed and each subsequent elsif clause is checked until an elsif clause is encountered that evaluates to true.

· If such an elsif clause is found, then the statements in braces following it are executed. Any subsequent elsif and else clauses are skipped.

· If all the if and elsif clauses are checked but none of their expressions evaluate to true, then if there is an else clause, then the statements enclosed in braces following the else clause are evaluated.

Note! Boolean expressions that evaluate to null are treated as false in conditionals.

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 10, Host Tables and DNS. 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's configuration file are related to dynamic updating:

· allow/deny dynamic-update;

· allow/deny update-A-record;

· allow/deny name-by-client;

· invalid-ddns-chars {fail | discard | replace [“chars”]};

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 not done at all for static assignments to BOOTP clients, and the support for static assignments to DHCP clients is to add DNS entries only.

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.

If you use the deny name-by-client statement or if the client does not send a name, you must specify the host name in the configuration file using one of the following methods:

· Using option host-name “name” (see the Host Name Generation section)

· Specifying use-host-decl-names on in conjunction with host declarations.

If the hostname specified by the client contains invalid characters for DNS, the DHCP server can handle them one of three ways:

· Consider it a failure and not do the dynamic update.

· Throw away the invalid characters.

· Replace the invalid characters with specified valid characters.

This behavior is controlled by the invalid-ddns-chars 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 10, Host Tables and DNS, the DNS Zone Information Files section 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. Also, the RRs are deleted for expired leases periodically.

Transaction Signatures (TSIG)

The DHCP server supports using Transaction Signatures (TSIG) on dynamic updates to DNS. Note that you need a DNS server that supports TSIG, such as MultiNet’s BIND server.

The use of TSIG can be enabled or disabled by using the secure-ddns statement in the configuration file. The default is to not use TSIG. The use of TSIG can be turned on or off on a per subnet basis. Turn on the use of TSIG using:

secure-ddns on;

For each DNS server that you want to use TSIG with, you must specify a key using the key declaration:

key ip-address {
[ algorithm "hmac-md5"; ]
key-id "key-name";
secret "key";
}

· ip-address is the IP address of the DNS server

· algorithm specifies the algorithm to use. The only supported algorithm is "hmac-md5". This statement is optional.

· key-id specifies the name of the key as a string. This must match the key name being used by the DNS server (e.g., configured in named.conf).

· secret specifies the secret key to use in base-64 format. This must match the secret key used by the DNS server (in named.conf).

An example key declaration for the DNS server at IP address 10.9.8.7 is:

key 10.9.8.7 {
key-id "dhcp-tsig";
secret "A5vhC+DjsocELGEYhj0iBBSQRgJvxnY/emD0C3kRtEpo";
};

Host Name Generation

Some DHCP clients require that the server send them a host name. The MultiNet 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 Dynamic Updates Within DHCP 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

· allow name-by-client is specified and the client does not send a host name, or

· deny name-by-client is specified and the DHCP server does not find a host name in the configuration file or in DNS (if get-lease-hostnames is set).

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 the table belowError! Reference source not found.). 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! 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. (in hex). For example: 0174657374.
%-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”.
%P	Printable characters from the client ID. For example: if the client ID was 0174657374, the 01 is thrown away and the resulting hostname is “test”.
%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

The below table describes the declarations and parameters you can use in a configuration file.

Statement	Description
add	Use the add statement to add a client to the class whose name is specified in class-name. Important! Because this statement executes after IP address allocation is completed, class membership caused by this statement cannot be used in the address allocation process. add “class-name”;
algorithm	Used only inside of key declarations, the algorithm statement specifies the algorithm to use for Transaction Signatures (TSIG) on dynamic DNS updates. The only supported algorithm is "hmac-md5". This statement is optional. algorithm "hmac-md5";
allow and deny	Use the allow and deny statements to control the behavior of the DHCP server. The allow and deny keywords have different meanings depending on the context. · In a pool context, use these keywords to set up access lists for address allocation pools. · In other contexts, use these keywords to control general server behavior with respect to clients based on scope.
allow and deny in scope	These allow and deny statements work the same way whether the client is sending a DHCPDISCOVER or a DHCPREQUEST message, · an address is allocated to the client (either the old requested address or a new address), and then, · that address is tested to see if it is okay for the client to have it. If the client requested it, and it is not okay, the server sends a DHCPNAK message. Otherwise, the server does not respond to the client. If it is okay to give the address to the client, the server sends a DHCPACK message. Note! These are not recommended for use inside pool declarations. See the Pool Permit Lists section for an important note. 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. An unknown client is one that does not have a host declaration. The default is to allow dynamic address assignments to unknown clients. allow unknown-clients; deny 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. allow bootp; deny bootp; Use the dynamic-bootp flag to tell the DHCP server to dynamically assign addresses to bootp clients or to not do so. The default is to allow dynamic bootp for IP addresses declared in pool declarations. The default for range statements outside of pool declarations is set by the presence or absence of the dynamic-bootp keyword. Deny dynamic-bootp overrides the dynamic-bootp range key word. allow dynamic-bootp; deny dynamic-bootp; 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. 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. allow booting; deny booting; 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. allow dynamic-update; deny dynamic-update; 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. allow name-by-client; deny name-by-client; 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 for authoritative subnets, and to deny DHCPINFORM messages for non-authoritative subnets. allow dhcpinform; deny dhcpinform; 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. allow update-A-record; deny update-A-record; Use the ras-servers flag to tell the DHCP server to respond to queries from Microsoft Windows RAS Servers or to not respond to NT RAS queries. The default is to allow NT RAS queries. allow ras-servers; deny ras-servers; Allow/deny ras-servers is supported for backward compatibility. The way to do deny ras-servers in version 3.0 of DHCP (MultiNet v5.1) is to use a conditional statement: if substring (option dhcp-client-identifier, 1,3) = “RAS” { deny booting; }
allow and deny in pool declarations	See the Pool Permit Lists section for discussion, defaults, and important notes. Use known clients to allow or prevent allocation from this pool to any client that has a host declaration. A client is known if it has a host declaration in any scope. allow known clients; deny known clients; Use unknown clients to allow or prevent allocation from this pool to any client that has no host declaration. allow unknown clients; deny unknown clients; Use members of “class” to allow or prevent allocation from this pool to any client that is a member of the named class. allow members of “class-name”; deny members of “class-name”; Use dynamic bootp clients to allow or prevent allocation from this pool to any BOOTP client. allow dynamic bootp clients; deny dynamic bootp clients; Use all clients to allow or prevent allocation from this pool to all clients. You can use this, for example, when you want to write a pool declaration but you want to hold it in reserve; or when you want to renumber your network quickly, and thus want the server to force all clients that have been allocated addresses from this pool to obtain new addresses immediately when they next renew their leases. allow all clients; deny all clients;
always-broadcast	Use the always-broadcast statement to cause the DHCP server to always broadcast its responses. This feature is to handle clients who do not set the broadcast flag in their requests and yet require a broadcast response. We recommend you restrict the use of this feature to as few clients as possible. always-broadcast flag;
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;
[not] authoritative	When the DHCP server receives a DHCPREQUEST message from a DHCP client requesting a specific IP address, the DHCP protocol requires that the server determine whether the IP address is valid for the network to which the client is attached. If the address is not valid, the DHCP server should respond with a DHCPNAK message, forcing the client to acquire a new IP address. To make this determination for IP addresses on a particular network segment, the DHCP server must have complete configuration information for that network segment. Unfortunately, it is not safe to assume that DHCP servers are configured with complete information. Therefore, the DHCP server normally assumes that it does not have complete information, and thus is not sufficiently authoritative to safely send DHCPNAK messages as required by the protocol. This default assumption should not be true for any network segment that is in the same administrative domain as the DHCP server. For such network segments, the authoritative statement should be specified, so that the server sends DHCPNAK messages as required by the protocol. If the DHCP server receives requests only from network segments in the same administrative domain, you can specify the authoritative statement at the top of the configuration file (in the global scope). authoritative; not authoritative;
class	This statement groups clients together based on information they send. A client can become a member of a class in the following ways: · through an add statement · based on the class’s matching rules · because the client matches a subclass of that class Class-name is the name of the class and is used in: · add statements · members of permit statements · subclass declarations for subclasses of the named class When a packet is received from a client, every class declaration is examined for a match, match if, or spawn statement. That statement is checked to see if the client is a member of the class. The class declaration statements are lease limit, match, match if, and spawn with. class “class-name” {[ statements ][ declarations ]}
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 “infinite”. The default is 43,200 seconds (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 “infinite”. 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-bootp-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	To make a static IP address assignment for a client, the client must match a host declaration, as described later. In addition, the host declaration must contain a fixed-address declaration. A fixed-address declaration specifies one or more IP addresses or domain names that resolve to IP addresses. If a client matches a host declaration, and one of the IP addresses specified in the host declaration is valid for the network segment to which the client is connected, the client is assigned that IP address. A static IP address assignment overrides a dynamically assigned IP address that is valid on that network segment. That is, if a new static mapping for a client is added after the client has a dynamic mapping, the client cannot use the dynamic mapping the next time it tries to renew its lease. The DHCP server will not assign an IP address that is not correct for the network segment to which the client is attached and will not override a valid dynamic mapping for one network segment based on a static mapping that is valid on a different network segment. You can specify a domain name instead of an IP address in a fixed-address declaration. However, you should do this only for long-lived domain name records — the DHCP server only looks up the record on startup. So, if the record changes while the server is running, the server continues to use the record’s former value. 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 {[statements] [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	The host declaration provides information about a particular client. Name should be a unique name for the host declaration, but a specific meaning is not required. If the use-host-decl-names flag is enabled, name is sent in the host-name option if no host-name option is specified. Host declarations match DHCP or BOOTP clients based on either the client's hardware address or the dhcp-client-identifier option that the client sends. BOOTP clients do not normally send a dhcp-client-identifier option. So, you must use the hardware address for all clients that might send BOOTP protocol requests. The host declaration has three purposes: · to assign a static IP address to a client · to declare a client as "known" · to specify a scope in which statements can be executed for a specific client You can make the DHCP server treat some DHCP clients differently from others if host declarations exist for those clients. Any request coming from a client that matches a host declaration is considered to be from a "known" client. Requests that do not match any host declaration are considered to be from "unknown" clients. You can use this knowledge to control how addresses are allocated. It is possible to write more than one host declaration for a client. If you want to assign more than one static address to a given client, you can either specify more than one address in the fixed-address statement or you can write multiple host declarations. Multiple host declarations are needed if the client has different requirements (scopes) on different subnets. For each IP address that requires a different scope, one host declaration should exist. A client can be in the scope of only one host declaration at a time. Host declarations with static address assignments are in scope for a client only if one of the address assignments is valid for the network segment to which the client is connected. If you want to boot a client using static addresses on some subnets, and using dynamically assigned addresses on other subnets, you need to write a host declaration with no fixed-address statement. There can be only one such host declaration per client. Its scope is used whenever that client receives a dynamically assigned address. host name { [statements] [declarations] }
if	The if statement conditionally executes statements based on the values the client sends or other information. See the Conditional Behavior section for more information. if boolean-expression { [statements] } [elsif boolean-expression { [statements] }] [else { [statements] } ]
invalid-ddns-chars	This statement specifies how DHCP should handle invalid characters in the hostname for Dynamic DNS updates (DDNS). fail tells DHCP to display a message and not perform any DNS updates if there are any invalid characters in the hostname. This is the same as the behavior of the DHCP server in MultiNet V4.2. This is the default. invalid-ddns-chars fail; discard tells DHCP to throw away the invalid characters in the hostname. invalid-ddns-chars discard; replace tells DHCP to replace the invalid characters with the specified character(s). If none are specified, the default replacement character is the hyphen ('-'). invalid-ddns-chars replace ["characters"];
key	The key declaration specifies keys to use for Transaction Signatures (TSIG) to sign dynamic DNS updates. See the Transaction Signatures section. key _ip-address_ { [ algorithm "algorithm-name"; ] key-id "key-name"; secret "key"; }
key-id	Used only inside of key declarations, the key-id statement specifies the name of the key to use for Transaction Signatures (TSIG) on dynamic DNS updates. This key name must match the name that the DNS server is using (as specified in named.conf). key-id "key-name";
lease limit	This statement causes the DHCP server to limit the number of members of a class that can hold a lease at any one time. This limit applies to all addresses the DHCP server allocates in the class, not just addresses on a particular network segment. · If a client is a member of more than one class with lease limits, the server assigns the client an address based on either class. · If a client is a member of one or more classes with limits and one or more classes without limits, the classes without limits are not considered. lease limit limit;
lease-scan-interval	This statement specifies how frequently to scan for expired leases. The default is 60 seconds. lease-scan-interval seconds;
match	data-expression is evaluated using the contents of a client’s request. If it returns a value that matches a subclass of the class in which the match statement appears, the client is considered a member of both the subclass and the class. match data-expression;
match if	boolean-expression is evaluated when the server receives a packet from the client. If it is true, the client is considered a member of the class. The boolean-expression may depend on the contents of the packet the client sends. match if boolean-expression;
max-delayed-acks	Use the max-delayed-acks statement to specify the maximum number of DHCPACKs to batch up. The default is 8. To disable the delaying of DHCPACKs, specify a value of 1. 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. max-delayed-acks count;
max-lease-time	Use the max-lease-time statement to assign the maximum amount of time (in seconds) to a lease. The only exception to this is Dynamic BOOTP lease lengths because they are not specified by the client and are not limited by this maximum. The infinite lease value is “infinite”. The default is 86,400 seconds (24 hours). Note! You should set the value of max-lease-time at least as large as default-lease-time. max-lease-time time;
min-lease-time	Use the min-lease-time statement to assign the minimum length in seconds to a lease. The infinite lease value is “infinite”. By default, there is no minimum. min-lease-time should be less than or equal to default-lease-time and max-lease-time. min-lease-time time;
min-secs	Use the min-secs statement to assign the minimum amount of time (in seconds) it takes for the DHCP server to respond to a client’s request for a new lease. The number of seconds is based on what the client reports in the secs field of the requests it sends. The maximum value is 255 seconds. Usually, setting this to one second results in the DHCP server not responding to the client's first request, but always responding to the client’s second request. You can use the min-secs statement to set up a secondary DHCP server to never offer an address to a client until the primary server has been given a chance to do so. If the primary server is down, the client binds to the secondary server; otherwise, clients should always bind to the primary. Note! This does not permit a primary server and a secondary server to share a pool of dynamically-allocatable addresses. See information about Safe-failover in this chapter. min-secs seconds;
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). 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;
one-lease-per-client	Use the one-lease-per-client statement to have the server free any other leases the client holds when the client sends a DHCPREQRUEST for a particular lease. This presumes the client has forgotten any lease not mentioned in the DHCPREQUEST. For example, the client has only a single network interface and it does not remember leases it is holding on networks to which it is not currently attached. Neither of these assumptions are guaranteed or provable, so use caution in the use of this statement. one-lease-per-client flag;
option	This statement specifies actual DHCP protocol options to send to the client. The option statement is described in the DHCP Options section.
option definition	This statement assigns a name and a type to an option code. See the Defining New Options section for more information. option name code code = definition;
option space	This statement specifies a new option space. This declaration must precede all definitions for options in the space being specified. Space-name should be the name of the option space. Currently three option space names are predefined: · dhcp (default) · agent · server If an option name is specified without an option space, it is assumed the name refers to an option in the dhcp option space. For example, the option names dhcp.routers and routers are equivalent. option space space-name;
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;
pool	This statement specifies an address pool from which IP addresses can be allocated. This pool can be customized to have its own permit list to control client access and its own scope to declare pool-specific parameters. You can put pool declarations within subnet declarations or within shared-network declarations. You can use the range declaration to specify the addresses in a particular pool. · For subnet declarations: specified addresses must be correct within the pool declaration within which it is made. · For shared-network declarations: specified addresses must be on subnets that were previously specified within the same shared-network declaration. pool {[permit list][range declaration][statements]}
range	For any subnet on which addresses are assigned dynamically, there must be at least one range declaration. The range declaration specifies that the server may allocate to DHCP clients every address, from low-address to high-address. You can specify a single IP address by omitting high-address. All IP addresses in the range should be on the same subnet. If the range declaration appears within a subnet declaration, all addresses should be on the declared subnet. If the range declaration appears within a shared-network declaration, all addresses should be on subnets already declared within the shared-network declaration. You may specify the dynamic-bootp flag if addresses in the specified range can be dynamically assigned to both BOOTP and DHCP clients. Note! The dynamic-bootp flag was deprecated in version 3.0 (MultiNet v5.1) of the DHCP server in favor of declaring the address within a pool and specifying in the permit list that dynamic allocation for BOOTP clients is permitted. range [dynamic-bootp] low-address [high-address];
requested-options-only	Use the requested-options-only statement to send just the options requested by the client. To send a specific set of options, set requested-options-only to true and specify the dhcp-parameter-request-list option. 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; } We recommend you restrict the use of this feature to as few clients as possible. requested-options-only flag;
secret	Used only inside of key declarations, the secret statement specifies the actual secret key to use for Transaction Signatures (TSIG) on dynamic DNS updates. The format is base-64. The value must match the key used by the DNS server (as specified in named.conf). secret "key";
secure-ddns	Use the secure-ddns statement to cause the DHCP server to use Transaction Signatures (TSIG) to sign dynamic DNS updates. The default is to not use TSIG. secure-ddns flag;
server-identifier	The server-identifier statement is equivalent to the dhcp-server-identifier option. See the dhcp-server-identifier option for more information 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 {[statements] [declarations]}
site-option-space	Use the site-option-space statement to determine the option space from which site-local options are taken. Site-local options have codes ranging from 128 to 254. If no site-option-space is specified, site-specific options are taken from the default option space. site-option-space option-space;
spawn with	data-expression must evaluate to a non-null value for the server to look for a subclass of the class that matches the evaluation. · If such a subclass exists, the client is considered a member of both the subclass and the class. · If no such subclass exists, one is created and recorded in the lease database, and the client is considered a member of the new subclass as well as the class. spawn with data-expression;
subclass	This statement specifies a subclass of the class named by class-name. Class-data should be either · a text string enclosed in quotes, or · a list of bytes expressed in hexadecimal, separated by colons. Clients match subclasses after evaluating the match or spawn with statements in the class declaration for class-name. If the evaluation matches class-data, the client is a member of the subclass and the class. subclass “class-name” class-data; subclass “class-name” class-data { [statements] }
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 {[statements][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.example.com; } } is equivalent to host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.example.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, use-lease-addr-for-default-route is preferred. use-lease-addr-for-default-route flag;
user-class	This statement has been deprecated in favor of the more powerful class statement. See the example in the Vendor Encapsulated Options section.
vendor-class	This statement has been deprecated in favor of the more powerful class statement. See the example in the Vendor Encapsulated Options section.
vendor-option-space	Use the vendor-option-space statement to instruct the server to construct a vendor-encapsulated-options option using all the defined options in the option space. If no vendor-encapsulated-options option is defined, the server sends this option to the client, if appropriate. vendor-option-space option-space;

Expressions

The DHCP server can evaluate expressions while executing statements. The DHCP server’s expression evaluator returns the following types:

· A boolean, a true or false (on or off) value.

· An integer, a 32-bit quantity that may be treated as signed or unsigned, depending on the context.

· A string of data, a collection of zero or more bytes. Any byte value is valid in a data string — the DHCP server maintains a length rather than depending on a NUL termination.

Expression evaluation is performed when a request is received from a DHCP client. Values in the packet sent by the client can be extracted and used to determine what to send back to the client. If the expression refers to a field or option in the packet for which there is no value, the result is null. Null values are treated specially in expression evaluation. A Boolean expression that returns a null value is considered false. A data expression that returns a null value generally results in the statement using the value not having any effect.

The following is an example of using four types of expressions to produce the name of a PTR record for the IP address being assigned to a client:

concat (binary-to-ascii (10, 8, “.”, reverse (1, leased-address)),
“.in-addr.arpa.”);

BOOLEAN EXPRESSIONS

The following are the boolean expressions supported by DHCP.

boolean-expression-1 and boolean-expression-2	The and operator evaluates to true if both boolean expressions evaluate to true. The and operator evaluates to false if either boolean expression does not evaluate to true. If either of the boolean expressions is null, the result is null.
boolean-expression-1 or boolean-expression-2	The or operator evaluates to true if either of the boolean expressions evaluate to true. The or operator evaluates to false if both of the boolean expressions evaluate to false. If either of the boolean expressions is null, the result is null.
check “class-name”	The check operator evaluates to true if the packet being considered comes from a client in the specified class. Class-name must be a string that corresponds to the name of a defined class.
data-expression-1 = data-expression-2	The = operator compares the results of evaluating two data expressions, evaluating to true if they are the same; evaluating to false if they are not. If one of the expressions is null, the result is null.
exists option-name	The exists expression evaluates to true if the specified option exists in the incoming DHCP packet.
known	The known expression evaluates to true if the client whose request is being processed is known; that is, if the client has a host declaration.
not boolean-expression	The not operator evaluates to true if the boolean expression evaluates to false. The not operator evaluates to false if the boolean expression evaluates to true. If the boolean expression evaluates to null, the result is null.

DATA EXPRESSIONS

The following are the expressions supported by DHCP that return a data string.

binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)	numeric-expr1, numeric-expr2, data-expr1, and data-expr2 are all evaluated as expressions and the results of those evaluations are used as follows. The binary-to-ascii operator converts the binary data in data-expr2 into an ASCII string, using data-expr1 as a separator. How the conversion is done is controlled by numeric-expr1 and numeric-expr2. · numeric-expr1 specifies the base to convert into. Any value 2 through 16 is supported. For example, a value of 10 would produce decimal numbers in the result. · numeric-expr2 specifies the number of bits in data-expr2 to treat as a single unit. The value can be 8, 16, or 32. This example converts the binary value of an IP address into its dotted decimal equivalent: binary-to-ascii(10, 8, ".", 168364039) The result would be the string "10.9.8.7".
colon-separated hexadecimal list	A list of hexadecimal octet values, separated by colons, may be specified as a data expression. A single hexidecimal number, appearing in a context where a data string is expected, is interpreted as a data string containing a single byte.
concat (data-expr1, data-expr2)	data-expr1 and data-expr2 are evaluated and the concatenated result of these two evaluations is returned. · If either subexpression evaluates to null, the result is the value of the expression that did not evaluate to null. · If both expressions evaluate to null, the result is null.
encode-int (numeric-expr, width)	numeric-expr is evaluated and encoded as a data string of the specified width, in network byte order (with the most significant byte first). If numeric-expr evaluates to null, the result is null.
hardware	The hardware operator returns a data string whose first element is the htype field of the packet being considered, and whose subsequent elements are the first hlen bytes of the chaddr field of the packet. If there is no packet, or if the RFC 2131 hlen field is invalid, the result is null. Supported hardware types are: · ethernet (1) · token-ring (6) · fddi (8)
leased-address	In any context where the processing client request has been assigned an IP address, this data expression returns that IP address.
option option-name	The option operator returns the contents of the specified option in the incoming DHCP packet.
packet (offset, length)	The packet operator returns the specified portion of the packet being considered. The packet operator returns a value of null where no packet is being considered. Offset and length are applied to the contents of the packet as in the substring operator. The link-layer, IP, and UDP headers are not available.
reverse (numeric-expr1, data-expr2)	numeric-expr1 and data-expr2 are evaluated. The result of data-expr2 is reversed in place, using chunks of the size specified in numeric-expr1. For example, if numeric-expr1 evaluates to four and data-expr2 evaluates to twelve bytes of data, the reverse expression evaluates to twelve bytes of data constructed in the following way: · the last four bytes of the input data, · followed by the middle four bytes, · followed by the first four bytes.
substring (data-expr, offset, length)	The substring operator evaluates the data expression and returns the substring of the result of that evaluation that starts offset bytes from the beginning and continues for length bytes. Offset and length are numeric expressions. · If data-expr, offset, or length evaluate to null, the result is null. · If offset is greater than or equal to the length of the evaluated data, a zero-length data string is returned. · If length is greater than the remaining length of the evaluated data after offset, a data string containing all data from offset to the end of the evaluated data is returned.
suffix (data-expr, length)	The suffix operator evaluates data-expr and returns the last length bytes of that evaluation. Length is a numeric expression. · If data-expr or length evaluate to null, the result is null. · If length evaluates to a number greater than the length of the evaluated data, the evaluated data is returned.
“text”	A text string, enclosed in quotes, may be specified as a data expression. The string returns the text between the quotes, encoded in ASCII.

NUMERIC EXPRESSIONS

Numeric expressions evaluate to an integer. In general, the precision of numeric expressions is at least 32 bits. However, the precision of such integers may be more than 32 bits.

extract-int (data-expr, width)	The extract-int operator extracts an integer value in network byte order after evaluating data-expr. Width is the width in bits (either 8, 16, 32) of the integer to extract. If the evaluation of data-expr does not provide an integer of the specified size, a value of null is returned.
number	Number can be any numeric value between zero and the maximum representable size.

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 in the default dhcp option space that can be declared, are in the table below.

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

An option name is an optional option space name followed by a period (“.”) followed by the option name. The default option space is dhcp. There are two other predefined option spaces: agent and server. You can also define option spaces of your own. See the sections Relay Agent Information Option and Defining New Options in this chapter.

Option data comes in these formats:

· The ip-address data type can be entered either as an explicit IP address (e.g., 239.254.197.10) or as a domain name (e.g., haagen.isc.org). When entering a domain name, be sure that the domain name resolves to the single IP address.

· The int32 and uint32 data types specify signed and unsigned 32-bit integers.
The int16 and uint16 data types specify signed and unsigned 16-bit integers.
The int8 and uint8 data types specify signed and unsigned 8-bit integers. Unsigned 8-bit integers are also sometimes referred to as octets.

· The string data type specifies an NVT ASCII string. It must be enclosed in quotation marks. For example, option domain-name “isc.org”;

· The flag data type specifies a boolean value. Booleans can be either true (ON) or false (OFF). You can use TRUE and FALSE, or ON and OFF.

· The data-string data type specifies either an NVT ASCII string enclosed in quotation marks, or a series of octets specified in hexadecimal, separated by colons. For example, option dhcp-client-identifier “CLIENT-FOO”; or option dhcp-client-identifier 43:4c:49:54:2d:46:4f:4f;

Strings and data-strings when enclosed in quotation marks can contain normal C-type characters such as “\t” for a tab.

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.

Also, option data may be specified using an expression that returns a data string (see the Expressions section). The syntax is

option option-name = data-expression;

Standard DHCP Options

This table describes the standard DHCP options. Underlined items indicate user input items.

Note! All of these options could be specified with the dhcp option space listed explicitly. For example:

option dhcp.bootfile-name “bootfile.lis”;

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. 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.
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. Note! NetBIOS is the same as WINS.
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. 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 1305) 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 as a character string 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 on the client’s subnet, listing the 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 number 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. See the Vendor Encapsulated Options section.
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.

Relay Agent Information Option

A relay agent can add a series of encapsulated options to a DHCP packet when relaying that packet to the DHCP server. The server can make address allocation decisions (or whatever decisions it wants) based on these options. The server returns these options in any replies it sends through the relay agent. The relay agent can use the information in these options for delivery or accounting purposes.

The relay agent option has two suboptions. To reference these options in the DHCP server, specify the option space name agent, followed by a period, followed by the option name.

Note! It is not useful to specify these options to be sent.

option agent.circuit-id string;	The circuit-id suboption encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for agents who will use it in relaying DHCP responses back to the proper circuit. The format of this option is defined to be vendor-dependent.
option agent.remote-id string;	The remote-id suboption encodes information about the remote host end of a circuit. Examples include the following: caller ID information, username information, remote ATM address, and cable modem ID. This is an opaque object that is administratively guaranteed to be unique to a particular remote end of a circuit.

Defining New Options

You can define new options with the DHCP server. Each DHCP option has the following:

· A name, used by you to refer to the option.

· A code, a number used by the DHCP server to refer to the option.

· A structure, describing what the contents of the option look like.

To define a new option, choose a name that is not in use for any other option. For example, you cannot use host-name because the DHCP protocol already defines a host-name option. You should refer to the options listed in this chapter as these are all the DHCP options in use by MultiNet.

After choosing a name, choose a code. For site-local options, all codes between 128 and 254 are reserved for DHCP options, so you can use any one of these.

The structure of an option is the format in which the option data appears. The DHCP server supports a few simple types: for example, integers, booleans, strings, and IP addresses. The server also supports the ability to define arrays of single types or arrays of fixed sequences of types. The syntax for declaring new options is:

option new-name code new-code = definition ;

The values of new-name and new-code are the name and the code you have chosen for the new option. The definition is one of the following simple option type definitions.

BOOLEAN	option new-name code new-code = boolean ; An option of type boolean is a flag with a value of either ON (true) or OFF (false). For example: option use-zephyr code 180 = boolean; option use-zephyr on;
INTEGER	option new-name code new-code = sign integer width ; The sign token should either be blank, unsigned, or signed. The width can be either 8, 16 or 32, referring to the number of bits in the integer. For example, a definition of the sql-connection-max option and its use: option sql-connection-max code 192 = unsigned integer 16; option sql-connection-max 1536;
IP-ADDRESS	option new-name code new-code = ip-address ; An option of type ip-address can be expressed either as a domain name or as an explicit IP address. For example: option sql-server-address code 193 = ip-address; option sql-server-address sql.example.com;
TEXT	option new-name code new-code = text ; An option of type text encodes an ASCII text string. For example: option sql-default-connection-name code 194 = text; option sql-default-connection-name "PRODZA";
DATA STRING	option new-name code new-code = string ; An option of type string is a collection of bytes. It can be specified either as quoted text, like the text type, or as a list of hexadecimal octets separated by colons whose values must be between 0 and FF. For example: option sql-identification-token code 195 = string; option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
ARRAYS	Options can contain arrays of any of the above types except for the text and the string types. For example: option kerberos-servers code 200 = array of ip-address; option kerberos-servers 10.20.10.1, 10.20.11.1;
RECORDS	Options can contain data structures consisting of a sequence of data types, sometimes called a record type. For example: option contrived-001 code 201 = { boolean, integer 32, text }; option contrived-001 on 1772 "contrivance"; It is also possible to have options that are arrays of records. For example: option new-static-routes code 201 = array of { ip-address, ip-address, ip-address, integer 8 }; option static-routes 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;

Vendor Encapsulated Options

The DHCP protocol defines the vendor-encapsulated-options option. This allows vendors to define their own options that will be sent encapsulated in a standard DHCP option. The format of the vendor-encapsulated-options option is either a chunk of opaque data, or an actual option buffer just like a standard DHCP option buffer.

You can send this option to clients in one of two ways:

· define the data directly, using a text string or a colon-separated list of hexadecimal values

· define an option space, define some options in that option space, provide values for them, and specify that this option space should be used to generate the vendor-encapsulated-options option

To send a simple chunk of data, provide a value for the option in the right scope. For example:

option vendor-encapsulated-options
     2:4:AC:11:41:1:
    3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
     4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

To define a new option space to store vendor options, use the option space statement. The name can then be used in option definitions. For example:

option space SUNW;
option SUNW.server-address code 2 = ip-address;
option SUNW.server-name code 3 = text;
option SUNW.root-path code 4 = text;

Once you have defined an option space and some options, you can set up scopes that define values for those options and when to use them. For example, suppose you want to handle two different classes of clients. Using the option space definition, the previous option vendor-encapsulated-options example can be implemented using classes as follows:

class "vendor-classes" {
match option vendor-class-identifier;
}

option SUNW.server-address 172.17.65.1;
option SUNW.server-name "sundhcp-server17-1";

subclass "vendor-classes" "SUNW.Ultra-5_10" {
vendor-option-space SUNW;
option SUNW.root-path "/export/root/sparc";
}

subclass "vendor-classes" "SUNW.i86pc" {
vendor-option-space SUNW;
option SUNW.root-path "/export/root/i86pc";
}

Regular scoping rules apply. This lets you define values that are global in the global scope, and define values that are specific to a particular class in the local scope.

The vendor-option-space declaration indicates that in that scope the vendor-encapsulated-options option should be constructed using the values of all the options in the SUNW option space.

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, for example, the duration of the lease and to whom it is assigned.

The below table describes the statements the DHCP server puts into a lease file

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.
billing class “class-name”;	If this lease is a member of a class with “lease limit” set, this records that class.
billing subclass “class-name” subclass-data;	If this lease is a member of a subclass with “lease limit” set, this records the class and subclass.
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. The MultiNet installation supplies an empty MULTINET:DHCPD.LEASES file.

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 MULTINET:DHCPD.LEASES_OLD. Finally, the newly written lease database is moved into place.

Be aware of the following situation: if the DHCP server process is killed or the system crashes after the old lease database has been renamed but before the new lease database has been moved into place, the MULTINET:DHCPD.LEASES file disappears. The DHCP server will refuse to start. Do not create a new lease file when this happens. If you do, you will lose all your old bindings. Instead, rename MULTINET:DHCPD.LEASES_OLD to MULTINET: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 checks to see if there are 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.

Static Leases

Leases that are given to clients for statically assigned IP addresses are treated differently than those for dynamically assigned IP addresses. An address is statically assigned by using a host declaration with a fixed-address statement.

Static lease information is not saved by the DHCP server. This means that they are not recorded in the lease file (DHCPD.LEASES). If your configuration uses only statically assigned IP addresses, you will not see any entries in the lease file.

This also means that the NETCONTROL SHOW commands do not have any lease information to display for static assignments.

· For SHOW CLIENT, statically assigned IP addresses are not supported.

· For SHOW SUBNET and SHOW LEASES, statically assigned IP addresses are not shown.

· For SHOW ALL, SHOW HADDR, SHOW CID, and in the dump file produced by the DUMP command, statically assigned IP addresses are identified as "Static Assignment" and no lease information is shown.

· For STATISTICS and SHOW POOLS, statically assigned IP addresses are not included in the pool or subnet statistics.

DNS dynamic updates are supported only partially for static assignments. When the lease is granted, the appropriate A and PTR resource records are added automatically. However, since the lease information is not saved, the DHCP server does not delete the DNS entries when the lease expires or is released.

Registering Clients While the DHCP Server is Running

The DHCP server can register and unregister clients without having to restart the server. host declarations and subclass declarations can be added or removed from the running server using add and remove commands in an update file, by default MULTINET:DHCPD.UPDATES.

The commands that can be placed into the update file are described in the table below.

You would use host declarations if you are controlling access to IP addresses via allow/deny unknown-clients statements in your DHCPD.CONF configuration file. You would use subclass statements if you are controlling access to IP address pools using classes configured with the match statement and using pools with allow/deny members of _class_ statements.

Note! The registration or unregistration of a client via the update file only affects the running server. The host and subclass declarations must also be added to the DHCPD.CONF configuration file.

You tell the DHCP server to execute the commands in the update file using the NETCONTROL DHCP UPDATE command:

$ multinet netcontrol dhcp update

A different file name can optionally be specified:

$ multinet netcontrol dhcp update mydir:dhcpd.updates

You can verify the syntax of the update file before sending it to the DHCP server by using the -u flag on the dhcpd command line:

$ dhcpd :== $multinet:dhcpd.exe
$ dhcpd -t -u filename

The update file name is not optional. Note that the configuration file is read in before the update file. A different configuration file can be specified using the -cf flag.

You can check the DHCP server and see if a given host or subclass is known, for example to see if you need to add it, using the following netcontrol commands:

$ multinet netcontrol show isknown host hw-addr-or-client-id
$ multinet netcontrol show isknown subclass class-name subclass-data

Update File Statements

The below table describes the commands you can use in an update file.

Statement	Description
add host	Registers a client by adding the specified host declaration. The host declaration is in the same format as in the configuration file. This makes the specified hardware address and/or client identifier "known". add host name { [statements] } Note that static IP address assignments can be added by specifying the fixed-address statement in the host declaration.
add subclass	Registers a client by adding the specified subclass to the specified class. The class must be declared in the DHCPD.CONF configuration file. The subclass declaration is the same format as in the configuration file. This adds the specified subclass value as a member of the specified class. add subclass "class-name" subclass-data; add subclass "class-name" subclass-data { [statements] }
delete host	Un-registers a client by removing the specified host declaration. The host is specified by hardware address or client identifier. This makes the specified host "unknown". Note that all host declarations that match the hardware address or client identifier are deleted. delete host hw-addr-or-client-id;
delete subclass	Un-registers a client by removing the specified subclass from the specified class. This makes the specified subclass no longer a member of the class. delete subclass "class-name" subclass-data;

Examples:

add host fred {
hardware ethernet 01:02:03:04:05:06;
fixed-address 10.9.8.7;
option routers 10.9.8.1;
}
add host wilma {
option dhcp-client-identifier "wilma-cid";
}
delete host 01:02:03:04:05:06;
delete host "wilma-cid";

add subclass "gold" 01:01:02:03:04:05:06 {
option host-name "fred";
}
add subclass "silver" "wilma-cid";
delete subclass "gold" 01:01:02:03:04:05:06;
delete subclass "silver" "wilma-cid";

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! 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 failure, as well as 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 DHCP 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 MULTINET: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. On the Secondary system, create the boot file at MULTINET: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";

5. 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).

6. Copy the configuration file to the MULTINET 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.

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

8. 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 DHCP Safe-failover

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

· Server's mode of operation

· Server's own IP address

· Partner server's IP address

· Configuration ID

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 multinet:dhcpd.conf and multinet: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:

Mode	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's own address, the next IP address is the partner server's 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 will look for a configuration file named ALPHA.CONF, a lease file named ALPHA.LEASES, and a state file named ALPHA.STATE.

Below is an example boot file:

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 199.23.24.11 and the partner server's IP address 199.23.24.25. The partner server is a Secondary server. This follows from the current server being a Primary server.

If the mode of operation is "standalone", the server's IP address and partner server's IP address are not needed. The format is as follows:

standalone "config-id";

State File for DHCP Safe-failover

The state file is written by the DHCP server when it is running with DHCP Safe-failover enabled. The purpose of the state file is to save server state changes so that a server can "remember" its last state if it crashes or is re-started. Alternately, the state file can be used by the operator to force the DHCP server to start up in a desired mode (operator override). This feature allows the operator 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;]

server_state is one of the following:

failover-disabled	primary-comint	primary-conflict
startup	backup-comint	backup-conflict
primary-normal	primary-partnerdown	primary-recover
backup-normal	backup-partnerdown	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 Configuration File Statements

The statements shown in DHCP Server Parameters Error! Reference source not found.have been added to the DHCP configuration file for DHCP Safe-failover. These are in addition to the DHCP configuration file statements listed in DHCP Option Space OptionsError! Reference source not found.. All of the parameters in DHCP Server Parameters 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.

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;

DHCP Safe-failover Lease File Statements

The statements shown in the below table have been added to the DHCP lease file for DHCP Safe-failover. These are in addition to the DHCP lease file statements listed in DHCP Lease File StatementsError! Reference source not found..

Statement	Description
acked-sec-interval seconds;	Acknowledged secondary lease interval. For information, see the DHCP failover internet draft.
acked-sec-interval-start date;	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.
last-partner-transaction date;	The time when the partner last updated the lease.
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.
revoked;	The lease for this IP address has been revoked by the operator.
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

Transitioning to DHCP Safe-failover Partner Down State

There are three ways that the DHCP server can transition 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. The operator can put the DHCP server into Partner Down state by executing the following netcontrol command:

$ multinet netcontrol dhcp partnerdown

3. The operator can edit the DHCP server's state file and add a line to the end containing the Partner Down state and transaction number desired:

primary-partnerdown transaction-number;

backup-partnerdown transaction-number;

The next time the DHCP server is restarted, it starts up in Partner Down state. The operator can restart the DHCP server by executing the following netcontrol command:

$ multinet netcontrol dhcp restart

Setting DHCP Parameters

The DHCP service uses the parameters listed in the table below.

Parameter	Description
ACCOUNTING	This parameter determines if the DHCP server process performs VMS accounting. The default is 0 (OFF).
CONFIGFILE	The name of the configuration file. The default is MULTINET:DHCPD.CONF. Not used if DHCP Safe-failover is being used.
DEBUG	A decimal integer that is a bitmask of debugging levels used to select messages to pass to OPCOM and the debug log file specified in the DEBUG-FILE parameter. The debugging levels are (in decimal): 1 Fatal Errors 3 Errors and Warnings 7 Informationals 15 Debug Messages 31 Dump Packets (Formatted) 63 Dump Packets (Hex) By default, Fatal Errors, Errors, and Warnings are logged.
DEBUG-FILE	The name of the debug log file. Use this parameter to capture debug logging in a file. The default is that debug logging is not written to any file if LOG-TO-OPCOM is 1. If LOG-TO-OPCOM is 0, the default file is MULTINET:DHCPDEBUG.LOG
DUMPFILE	The name of the "dump" file. This is the output of the NETCONTROL DUMP command. The default is MULTINET:DHCPD.DUMP.
IMAGE-NAME	The name of the image to run in the DHCP server process. The default is MULTINET:DHCPD.EXE.
LEASEFILE	The name of the file DHCP uses to save client lease information to survive across reboots. To completely clear the lease information, delete the file specified and create an empty version. The default is MULTINET:DHCPD.LEASES. Not used if DHCP Safe-failover is being used.
LOG-DATE	This parameter determines whether the date is included in each entry in the debug log file. The default is 0; the date is not included.
LOG-TO-OPCOM	This parameter determines whether debug logging messages are written to OPCOM. Debug messages are also written to DEBUG-FILE parameter value if DEBUG-FILE is specified or this parameter is 0. Severe errors and warnings are always logged to OPCOM. The default is 1, everything is logged to OPCOM.
PROCESS-NAME	The name of the DHCP server process. The default is DHCP_SERVER.
SYS-ERROR	The name of a file that will contain anything written to SYS$ERROR by the DHCP server. This information could be helpful in diagnosing problems. The default is _NL:. This means SYS$ERROR is not directed to any file.
SYS-OUTPUT	The name of a file that will contain anything written to SYS$OUTPUT by the DHCP server. This information could be helpful in diagnosing problems. The default is _NL: meaning SYS$OUTPUT not directed to any file.
SWAP	This parameter determines whether process swapping is inhibited for the DHCP server process. The default is 1, swapping is enabled.
UPDATEFILE	The name of the update file. This file contains update commands that the DHCP server executes upon a NETCONTROL UPDATE command. The default is MULTINET:DHCPD.UPDATES.

You may set any of the parameters listed in DHCP Lease File StatementsError! Reference source not found., as shown in the following example:

$ MULTINET NETCONTROL DHCP SHUTDOWN (if DHCP is running)
$ MULTINET CONFIGURE /SERVER

MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT DHCP
[The Selected SERVER entry is now DHCP]
SERVER-CONFIG>SET PARAMETERS
Delete parameter "configfile MULTINET:DHCPD.CONF" ? [NO] RETURN
You can now add new parameters for DHCP. An empty line terminates.
Add Parameter: debug 3
Add Parameter: RETURN
[Service specific parameters for DHCP changed]
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$

Viewing DHCP Information

MultiNet provides two NETCONTROL commands for displaying information about the DHCP server:

· NETCONTROL SHOW (see the NETCONTROL SHOW Command section)

· NETCONTROL STATISTICS (see the NETCONTROL STATISTICS Command section)

NETCONTROL SHOW Command

The DHCP NETCONTROL SHOW command has seven subcommands: SHOW CLIENT, SHOW LEASES, SHOW SUBNET, SHOW ALL, SHOW HADDR, SHOW CID, and SHOW POOLS.

Viewing Lease Information for Specific IP Addresses

The DHCP NETCONTROL SHOW CLIENT command displays the current lease binding details on a particular IP address. It must be an IP address in the dynamic pool. Statically-bound IP addresses are not supported. The syntax for SHOW CLIENT is:

$ MULTINET NETCONTROL DHCP SHOW CLIENT dotted-decimal-ip-address

dotted-decimal-ip-address is the IP address of a client.

For example:

$ MULTINET NETCONTROL DHCP SHOW CLIENT 10.5.64.1
Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Fri 4-Aug-2003 3:23PM-EDT
< DHCP Client: 10.5.64.1
<     IP Address=10.5.64.1
<     State=Bound (expired)
<     Subnet Mask=255.255.255.0
<     Default Gateway=10.5.64.100
<     Hardware Address=00004400AABB
<     Client ID=74657374 (“test”)
<     Lease=300 secs, Obtained 06-Aug-2003 22:21:22 GMT Expires 16-Aug-2003 22:26:22 GMT (-75426 secs)
< End of Show DHCP Client

Viewing Lease Information for all Leased IP Addresses

The DHCP NETCONTROL SHOW LEASES command takes no arguments. It displays for all subnets the IP addresses that have leases (pending, active, or expired). Lease information for statically-assigned IP addresses is not available. For example:

$ MULTINET NETCONTROL DHCP SHOW LEASES

Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Wed 2-Aug-2015 2:32PM-EST
< List all leases
< Shared Network local
< Subnet 10.5.64.0 netmask 255.255.255.0
< Subnet 10.5.165.0 netmask 255.255.255.0
< Pool 1
<     IP Addr=10.5.64.1, State=Bound (expired), Lease Expires
03-Mar-2003 19:32:43 GMT (-4 secs)
<     IP Addr=10.5.64.13, State=Offered, Lease Expires 08-Aug-2003 19:34:07 GMT (80 secs)
<     IP Addr=10.5.64.2, State=Bound, Lease Expires 08-Aug-2003 19:36:52 GMT (245 secs)
< End of lease list

Viewing Address Pools for Specific Subnets

The DHCP NETCONTROL SHOW SUBNET command displays all of the DHCP address pools for the shared network that ip-address is in. It lists each subnet that is on the shared network and each IP address in each pool. Statically-bound IP addresses are not shown. The syntax for SHOW SUBNET is:

$ MULTINET NETCONTROL DHCP SHOW SUBNET dotted-decimal-ip-address

dotted-decimal-ip-address is any IP address in that subnet.

You would typically use the subnet value or an IP address from a pool for the subnet. For example:

$ MULTINET NETCONTROL DHCP SHOW SUBNET 10.5.64.0
Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Mon 14-Aug-2015 7:09PM-EDT
< List given Subnet pool
< Shared Network local
< Subnet 10.5.64.0 netmask 255.255.255.0
< Subnet 10.5.165.0 netmask 255.255.255.0
< Pool 1
< IP Addr=10.5.64.3, State=Free, No Lease
< IP Addr=10.5.64.1, State=Bound, Lease Expires 14-Aug-2003 22:21:14 GMT (2867 secs)
< End of Subnet pool list

Viewing Address Pools for All Subnets

The DHCP NETCONTROL SHOW ALL command takes no arguments. It shows the SHOW SUBNET output for all subnets in the DHCP server configuration. Then it prints information about all static assignments.

Note! For static assignments, lease information is not available. For example:

$ MULTINET NETCONTROL DHCP SHOW ALL
Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Tue 11-Jul-2015 11:24AM-EDT
< List all Subnet pools
< Shared Network local
< Subnet 10.5.64.0 netmask 255.255.255.0
< Subnet 10.5.165.0 netmask 255.255.255.0
< Pool 1
<     IP Addr=10.5.64.3, State=Free, No Lease
<     IP Addr=10.5.64.1, State=Bound, Lease Expires 15-Jul-2003 22:21:14 GMT (2867 secs)
< DHCP Static Assignments
<     IP Addr=10.5.64.15, State=(Static Assignment)
<     IP Addr=10.5.165.17, State=(Static Assignment)
<     IP Addr=10.5.165.200, State=(Static Assignment)
< End of Subnet pool lists

Viewing Matched Leases for Hardware Addresses

The DHCP NETCONTROL SHOW HADDR command shows all client entries that match a given hardware address. The clients can have leases on multiple subnets simultaneously.

Note! For hardware addresses that have static assignments, lease information is not available.

The syntax for the NETCONTROL SHOW HADDR command is

$ MULTINET NETCONTROL DHCP SHOW HADDR MAC_address

For example:

$ MULTINET NETCONTROL DHCP SHOW HADDR 00004400AABB
Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Fri 04-Aug-2015 4:41PM-EDT
< DHCP Hardware Address: 00004400AABB
<     IP Address=10.5.64.1
<     State=Bound (expired)
<     Subnet Mask=255.255.255.0
<     Default Gateway=10.5.64.100
<     Hardware Address=00004400AABB
<     Client ID=74657374 (“test”)
<     Lease=300 secs, Obtained 08-Aug-2003 22:21:22 GMT Expires 08-Aug-2003 22:26:22 GMT (-80091 secs)
< End of Show DHCP HAddr

Viewing Matched Leases for Client ID

The DHCP NETCONTROL SHOW CID command shows all client entries that match a given Client ID. The clients can have leases on multiple subnets simultaneously.

Note! For client IDs that have static assignments, lease information is not available, as shown in this example. The syntax for the NETCONTROL SHOW CID command is

$ MULTINET NETCONTROL DHCP SHOW CID Client_ID_in_hex

For example:

$ MULTINET NETCONTROL DHCP SHOW CID 7465737431
Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Mon 10-Jul-2015 6:36PM-EDT
< DHCP Client ID: 7465737431
<     IP Address=10.24.25.1
<     State=(Static Assignment)
<     Subnet Mask=255.255.255.0
<     Default Gateway=<none>
<     Hardware Address=<none>
<     Client ID=7465737431 (“test1”)
< End of Show DHCP Client ID

Viewing IP Address Pool Availability

The DHCP NETCONTROL SHOW POOLS command takes no arguments. It displays a table showing for each IP address pool the number of IP addresses that are available. An IP address pool corresponds to a shared-network statement, a subnet statement, or a pool statement in the DHCP configuration file. For each pool the following information is displayed:

Shared Network	The name from the shared-network statement or the subnet number from the subnet statement.
Pool	“Total” for the complete information for the shared network, otherwise a number identifying the pool. You can see which IP addresses are in which pools using the SHOW ALL or SHOW SUBNET command.
Total	The total number of IP addresses in the pool.
Abandoned	The number of IP addresses in the pool which were found in use on the network when they were thought to be free.
Reserved	If DHCP Safe-failover is in use, the number of IP addresses in the pool reserved for the secondary DHCP server. These addresses are unassigned but reserved for the secondary.
Available	The number of IP addresses in the pool available to be leased.

For example:

$ MULTINET NETCONTROL DHCP SHOW POOLS

Connected to NETCONTROL server on "LOCALHOST"
< x.process.com Network Control V5.5(10) at Fri 11-Feb-2015 5:25PM-EST
< List Pool Availability
< Shared Network       Pool       Total      Abandoned Reserved   Available
< --------------       ----       -----      --------- --------   ---------
< local                total      44         5          0          15
<                      1          44         5          0          15
< 10.12.1.0            total      128        2          0          57
<                      1          111        0          0          54
<                      2          11         2          0          0
<                      3          6          0          0          3
< End of pool availability list

NETCONTROL STATISTICS Command

The DHCP NETCONTROL STATISTICS command displays the number of clients in each shared network. This is supplied for backward compatibility only. Use SHOW POOLS instead.

Address Lease States in DHCP Dump Files

After obtaining a DHCP dump using MULTINET NETCONTROL DHCP DUMP, you will see fields in the dump preceded by a pound sign (#). Those fields are values created while the server is running. These fields are provided to help you troubleshoot problems. The lease states (denoted by # State= in the dump) are described in the below table.

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.
Reserved for Secondary	Used for DHCP Safe-failover: the address is set aside for the secondary server’s emergency use.
Static Assignment	The client identifier or hardware address is statically assigned; the binding does not expire.

Sample DHCPD.CONF File

Below is a sample DHCPD.CONF file.

#
# MULTINET: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.40;
    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.41;
    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;
}