Chapter 4
This chapter describes the DHCP/BOOTP Server. It combines the Dynamic Host Configuration Protocol (DHCP) server with the bootstrap protocol daemon (BOOTPD).
DHCP is the Dynamic Host Configuration Protocol. It centralizes and automates TCP/IP network configuration. The DHCP Server dynamically allocates IP addresses for hosts on the network from an available pool of addresses. In this way, new hosts or hosts that are frequently relocated can automatically get new IP addresses for a certain lease period.
DHCP is an extension of the Internet Bootstrap Protocol (BOOTP). DHCP offers a network host a temporary lease rather than an ownership of an IP address. The lease identifies the duration for which the client can safely use its dynamically assigned IP address. Lease lengths generally depend on the number of network users (crowding of the network) and the number of available IP addresses the DHCP server can assign. The network manager sets the lease length through parameters.
BOOTP uses UDP/IP to allow diskless systems to find their IP addresses, addresses of boot servers, and names of boot files. BOOTP can supply other client information, such as the addresses of name servers, gateways, and LPD servers.
In TCPware, the DHCP Server (DHCPD) is combined with the BOOTP Server (BOOTPD) to form the DHCP/BOOTP Server (DHCPD/BOOTPD).
Note! DHCP uses DNS for host names and IP addresses; thus, a malfunction in your DNS server can affect the DHCP server.
DHCP goes through an initializing, selecting, requesting, binding, renewal, rebinding, and expiration cycle when negotiating for an IP address, as shown in Figure 4-1.The process is basically as follows:
1 The client just added or relocated on the network requests an IP address by broadcasting a DHCPDISCOVER message to the local subnet over the well-known BOOTP server port. (The client can also go through a BOOTP router or relay agent to forward the DHCPDISCOVER to additional remote DHCP servers.) This is the initializing state.
2 The participating DHCP servers respond with a DHCPOFFER message if they have a valid configuration for the client. The client may get many of these messages, which contain the IP address and configuration data. (The servers make sure to reserve the addresses so as not to accidentally offer them to another client.) At this point the client enters the selecting state.
3 After selecting an address, the client broadcasts the selected address and name of the "winning" server (DHCP Server 1 in Figure 4-1) using a DHCPREQUEST message. This is the requesting state. All the other servers can now safely unreserve their addresses.
4 Server 1 sends the client a DHCPACK (acknowledgment) message with the negotiated IP address, the lease, and the network configuration parameters. The client now enters the binding state and can fully use the assigned IP address.
5 About halfway through the lease, the client sends Server 1 another DHCPREQUEST for a lease renewal, and enters the renewal state. If the server deems the lease renewable, it sends back another DHCPACK to update the lease (including any new parameters). The client now returns to the binding state, as in Step 4.
6 If the client cannot renew the lease (such as if Server 1 is down), the client waits until about 87.5% of the way through the lease and broadcasts another DHCPREQUEST to all DHCP servers. Any server can now return a DHCPACK containing the extended lease and updated parameters. This is the rebinding state.
7 When the lease reaches 100% expired, or a server sends back a DHCPNAK negative acknowledgment message, the client must give up the IP address. It then returns to the initializing state and has to start the address negotiation over again.
Figure 4-1 DHCP Address Request and Allocation Process
DHCP is defined in RFC 2131 and RFC 2132. Refer to them for more information.
Two DHCP servers are recommended for a network. The benefit of having more than one server is if one fails another is available to continue processing requests, ensuring that all hosts (old and new) are serviced continuously. Refer to DHCP Safe-failover Introduction for more information.
You can administer the DHCP server using the following TCPware Network Control Utility (NETCU) commands:
|
Command |
Description |
|
RELEASE DHCP ip-address |
Forces the DHCP server to act as if it heard a DHCPRELEASE message from the client for the given IP address. |
|
REMOVE DHCP ip-address |
Synonym for RELEASE DHCP. |
|
SET DHCP/DEBUG=value |
Sets the debug logging level to the given value. |
|
SET DHCP/NEWLOG |
Starts a new debug log file. |
|
SET DHCP/PARTNERDOWN |
For Safe-failover DHCP: causes the DHCP server to transition into Partner Down state. |
|
STOP/DHCP |
Causes the server to shut down. |
|
SHOW DHCP/ALL |
Displays SHOW DHCP/SUBNET output for all subnets, plus information about static assignments. |
|
SHOW DHCP/CLIENT_IDENTIFIER=client-id |
Displays all lease binding and static assignment details for the given client ID. |
|
SHOW DHCP/CONFIGURATION |
Writes all configuration and lease information to a dump file. |
|
SHOW DHCP/HARDWARE_ADDRESS=hardware-address |
Displays all lease binding and static assignment details for the given hardware address. |
|
SHOW DHCP/IP_ADDRESS=ip-address |
Displays lease binding details for the given IP address. Static assignments are not supported. |
|
SHOW DHCP/ISKNOWN host, subclass |
If host is specified, shows whether the given hardware address or client identifier is "known", that is if there is a host declaration for that hardware address or client identifier. If subclass is specified, shows whether the given subclass data exists as a subclass within the given class. |
|
SHOW DHCP/LEASES |
Displays brief information about each lease. |
|
SHOW DHCP/POOLS |
Displays address pool availability. |
|
SHOW DHCP/STATUS |
Checks if the DHCP server is running. |
|
SHOW DHCP/SUBNET=ip-address |
Displays brief information about each IP address in the same shared network as the given IP address. |
|
SHOW DHCP/VERIFY |
Checks the syntax of the configuration file and optionally the lease file and the update file. |
|
SHOW DHCP/VERSION |
Displays the version of the DHCP server. |
|
UPDATE DHCP |
Instructs the Dynamic Host Configuration Protocol (DHCP) server to process the update file and add or remove the specified host and subclass declarations. |
See the SHOW DHCP, SET DHCP, RELEASE DHCP, REMOVE DHCP, STOP/DHCP, and UPDATE DHCP command descriptions in the NETCU Command Reference.
You can configure the DHCP server using CNFNET by typing @TCPWARE:CNFNET DHCP.
You can configure the following items:
• Enable or disable the DHCP server.
• Set the debug logging level.
• Set the debug log file name.
• Include the date in the log file or not.
• Log debug messages to OPCOM or not.
See the DHCP configuration description in the Installation and Configuration Guide.
Whenever you modify the configuration file, it is good practice to verify the syntax by entering the following NETCU command:
$ NETCU SHOW DHCP/VERIFY[=(config=<config-file>)] -
_$ [/OUTPUT=<output-file>]
This command causes the DHCP server to run enough to read and parse the configuration file. The DHCP server displays a copyright notice and a message for each syntax error encountered. If the DHCP server displays only the copyright notice, the configuration file has no syntax errors.
The CONFIG option optionally specifies where the configuration file is. If you do not specify the CONFIG option, the DHCP server reads the default configuration file TCPWARE:DHCPD.CONF. The /OUTPUT qualifier optionally sends command output to the specified file.
If you modify TCPWARE:DHCPD.CONF after starting the DHCP server, reload the DHCP configuration by restarting the DHCP server by using @TCPWARE:RESTART DHCP. When the DHCP server restarts, it rereads the configuration file.
The DHCP_CONVERSION_TOOL assists in changing from the DHCP server in TCPware v5.3 and earlier to the DHCP server in TCPware v5.4 and later. This tool converts the configuration file and lease file from the 5.3 DHCP server to the format of the configuration and lease files of the 5.4 DHCP server. It is run automatically by the command procedure that starts the DHCP server, TCPWARE:DHCP_CONTROL.COM. However, it is recommended that you run the conversion tool and verify the output ahead of time.
The conversion tool reads the old DHCP configuration file or BOOTP configuration file and writes out a configuration file in the new format. All information from the old configuration file is in the new file. Information that does not have an equivalent in the new configuration file is represented with comment lines.
The conversion tool then reads the old lease file and writes out a lease file in the new format.
The old configuration and lease files are retained in their original location so you can use them to validate the new configuration and lease files.
You can also run the conversion tool directly by specifying the names of the input and output files at the command prompt. If they are not specified, the tool prompts you for them. Enter "NONE" for the file name if you do not have the input file. For example: if you do not have a lease file, then enter:
$ dhcpconvert :== $tcpware:dhcp_conversion_tool.exe
$ dhcpconvert dhcptab. none dhcpd.conf dhcpd.leases
Enter a question mark (?) to get help for the tool. The default file names are:
|
TCPWARE:DHCPTAB. |
The old DHCP configuration file. |
|
TCPWARE:BOOTPTAB. |
The old BOOTP configuration file. Read only if the DHCPTAB file does not exist. |
|
TCPWARE:DHCPD.CONF |
The new DHCP configuration file. |
|
TCPWARE:DHCP_LEASE.DAT |
The old DHCP lease file containing the lease status. |
|
TCPWARE:DHCPD.LEASES |
The new DHCP lease file. |
Warning! Review the output lease file carefully. The old TCPware lease file does not contain the hardware type, so the conversion tool usually uses ethernet. If you are using a token ring network, change the 'hardware ethernet' statements to 'hardware token-ring' statements. The old TCPware lease file also does not contain whether the ID was a hardware address or client identifier, so review carefully all 'uid' and 'hardware' statements.
TCPware supplies a template DHCP configuration file, TCPWARE:DHCPD_CONF.TEMPLATE, that contains comments and a number of examples to help you enter information for your hosts. Using this template as a guide, create a DHCP configuration file at TCPWARE:DHCPD.CONF (with any text editor) containing the entries you need for your network and hosts.
The dhcpd.conf file is a free-form ASCII text file. The file may contain extra tabs and new lines for formatting purposes and comments may be placed anywhere within the file (except within quotation marks). Comments begin with the # character and end at the end of the line. See Example 4-2. Keywords in the file are case-insensitive.
The file consists of a list of statements specify which fall into two categories: parameters and declarations.
Parameter statements always specify one of the following:
• How to do something (for example, how long a lease to offer)
• Whether to do something (for example, should the DHCP server provide addresses to unknown clients)
• What parameters to provide to the client (for example, 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:
option routers 204.254.239.1;
Note! The address is specified numerically; this is not required. If you have a different domain name for each interface on your router, it is appropriate to use the domain name for that interface instead of the numeric address. However, there may be only one domain name for all a router's IP addresses, and it would not be appropriate to use that name here.
Parameters starting with the option keyword correspond to actual DHCP options. Parameters that do not start with the option keyword either control the behavior of the DHCP server (for example, how long a lease the DHCP server will give out), or specify client parameters that are not optional in the DHCP protocol (for example, server-name and filename).
Each host can have host-specific parameters. These could include such things as the:
• 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 where ever that parameters are allowed, and will be applied according to the scope in which the parameter appears.
All parameters must be specified first before you can specify any declarations that depend on those parameters. Parameters should be set inside declarations so they can be set on a per-subnet or a per-host basis.
Declarations are used to:
• 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 is dynamically allocated on that subnet.
There are different declarations required for different situations. The following are 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 the two networks in a shared-network declaration.
Some sites may have departments that have clients on more than one subnet. 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 the declarations in a group declaration using the parameters that are common to that department.
• For clients with dynamically assigned addresses, group parameter assignments 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 Example 4-1.
• 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. If no such entry is found, it looks for an entry with no fixed-address parameter.
Imagine that you have a site with a lot of NCD X-Terminals. These terminals come in a variety of models, and you want to specify the boot files for each model. You could have host declarations for each server and group them by model:
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 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.
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.
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 Table 4-3 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 (TCPware v5.4) 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.
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(R) NT 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.
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.
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.
The DHCP server can be configured to perform conditional behavior depending on the packets it receives.
Conditional behaviour 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.
The DHCP server performs dynamic updates to DNS using DNS's dynamic updating functionality. To be sure that updates are allowed from the DHCP server, see Chapter 1, Domain Name Services. The allow-update { <address_match_list> }; statement in the Zone section enables the DNS server to allow updates from that system.
The following statements in the DHCP server configuration file are related to dynamic updating:
• 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 1, Domain Name Services for information about PTR resource records and A resource records.
When dynamic updating is allowed, the DHCP server adds the resource records whenever an IP address is leased to a client. The RRs are deleted if the IP address is released or if the IP address is leased to a different client. Also, the RRs are deleted for expired leases periodically.
Some DHCP clients require that the server send them a host name. The TCPware DHCP server can generate a host name if it cannot get the host name in another way. The generated host name can contain parts of the host's IP address, client ID, and/or MAC address. This host name is sent to the client and is combined with the domain name to create the Fully Qualified Domain Name (FQDN) required for dynamic DNS updates. See the DNS Dynamic Updates Within DHCP section. As described in the DNS updates section, the allow/deny name-by-client statement in the configuration file controls whether the DHCP server uses information from the client to determine the host name and FQDN.
The DHCP server generates a host name if it is enabled to do so and either of the following is specified:
• allow name-by-client and the client does not send a host name
• deny name-by-client 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 Table 4-2). The option host-name statement can be specified for example at the top level in a subnet statement, or in a host statement.
The key values are as follows. You can include more than one in the same host-name value.
Note! Some of these do not by themselves generate a unique identifier.
|
Key |
Meaning |
|
%A |
First byte of the host's IP address.Example: for address 10.24.25.201, the key would return 10. |
|
%B |
Second byte of the host's IP address.Example: for address10.24.25.201, the key would return 24. |
|
%C |
Third byte of the host's IP address.Example: for address 10.24.25.201, the key would return 25. |
|
%D |
Fourth byte of the host's IP address.Example: for address 10.24.25.201, the key would return 201. |
|
%H |
Host part of the host's IP address.Example: for address 10.24.25.201 with subnet mask 255.255.0.0, the key would return 6601. |
|
%I |
Client Identifier sent by the host. |
|
%-I |
Client ID as above, except that hyphens (-) are used to separate each byte. |
|
%M |
MAC address of the host. |
|
%-M |
MAC address of the host, as above, except that hyphens (-) are used to separate each byte. |
|
%N |
Host name sent by the client, if any. If none, "Host". |
|
%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.
Table 4-1 describes the declarations and parameters you can use in a configuration file.
See Table 4-9 for a list of DHCP Safe-failover-related configuration file statements.
Table 4-1 DHCP Statements (Continued)
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.");
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. |
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 hexadecimal 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 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. |
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 Table 4-2.
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;
Table 4-2 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";
Table 4-2 DHCP Option Space Options (Continued)
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.
Table 4-3 Agent Option Space Options (Continued)
|
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. |
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 can not 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 TCPware.
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.
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.
The DHCP server keeps a persistent database of leases it has assigned. This database is a free-form ASCII file containing a series of lease declarations. Every time a lease is acquired, renewed, or released, its new value is recorded at the end of the lease file. So, if more than one declaration appears for a given lease, the last one in the file is the current one.
Currently, the only declaration that is used in the dhcpd.leases file is the lease declaration.
lease ip-address {statements...}
Each lease declaration includes the client’s leased IP address. The statements within the braces define the duration of the lease and to whom it is assigned.
Table 4-4 describes the statements the DHCP server puts into a lease file.
See Table 4-9 for a list of DHCP Safe-failover related lease file statements.
Table 4-4 DHCP Lease File Statements (Continued)
The DHCP server requires that a lease database be present before it will start. Before starting the DHCP server for the first time, make sure there is a TCPWARE:DHCPD.LEASES file. If it doesn’t exist, create an empty one.
In order to prevent the lease database from growing without bound, the file is rewritten from time to time. First, a temporary lease database is created and all known leases are dumped to it. Then, the old lease database is renamed TCPWARE:DHCPD.LEASES_OLD. Finally, the newly written lease database is moved into place.
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 TCPWARE: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 TCPWARE:DHCPD.LEASES_OLD to TCPWARE:DHCPD.LEASES, restoring the old, valid lease file, and then start the DHCP server. This guarantees that a valid lease file will be restored.
Abandoned leases 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.
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 NETCU SHOW DHCP commands do not have any lease information to display for static assignments.
• For SHOW DHCP/IP_ADDRESS, statically assigned IP addresses are not supported.
• For SHOW DHCP/SUBNET and /LEASES, statically assigned IP addresses are not shown.
• For SHOW DHCP/ALL, /HARDWARE_ADDRESS, and /CLIENT_IDENTIFIER, and in the dump file produced by /CONFIGURATION, statically assigned IP addresses are identified as a static assignment and no lease information is shown.
• For SHOW DHCP/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.
After obtaining a DHCP dump using NETCU SHOW DHCP/CONFIGURATION, you will see fields in the dump preceded by a pound sign (#). Those fields are values created while the protocol is running and do not directly correlate with the DHCP options listed in Table 4-2. These fields are provided to help you troubleshoot problems. The lease states (denoted by # State= in the dump) are described in Table 4-5.
Table 4-5 DHCP Address Lease States (Continued)
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 TCPWARE:DHCPD.UPDATES.
The commands that can be placed into the update file are described in section Update File Statements 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 NETCU UPDATE DHCP command:
$ netcu update dhcp
A different file name can optionally be specified:
$ netcu update dhcp/filename=mydir:dhcpd.updates
You can verify the syntax of the update file before sending it to the DHCP server by using the NETCU SHOW DHCP/VERIFY command:
$ netcu show dhcp/verify=(update[=filename])
If the update file name is not specified, the file TCPWARE:DHCPD.UPDATES is read. Note that the configuration file is read in before the update file. A different configuration file can be specified using the CONFIG option:
$ netcu show dhcp/verify=(config=filename,update[=filename])
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 netcu commands:
$ netcu show dhcp/isknown host hw-addr-or-client-id
$ netcu show dhcp/isknown subclass class-name subclass-data
Table 4-6 describes the commands you can use in an update file.
Table 4-6 DHCP Update File Commands
|
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; |
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";
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.
To configure your DHCP servers to use Safe-failover, perform the following steps:
1 Choose one system to be the Primary and a second system to be the Secondary.
2 Determine the IP addresses of the Primary and Secondary systems. If a system has more than one IP address, choose one to use for DHCP Safe-failover messages.
3 On the Primary system, create the boot file at TCPWARE:DHCPD.BOOT with the keyword "primary", the primary and secondary IP addresses, and configuration ID. On the primary system, the configuration ID would normally be "dhcpd". See Boot File for DHCP Safe-failover for more information about boot files.
Primary system boot file syntax:
primary <primary-ip> <secondary-ip> "config-id";
4 On the Secondary system, create the boot file at TCPWARE:DHCPD.BOOT with the keyword "secondary", the secondary and the primary IP addresses, and configuration ID. On the secondary system, the configuration ID may be "dhcpd" or may be a name that refers to the primary. Either way, the names of the configuration, lease, and state files must match this name.
Secondary system boot file syntax:
secondary <secondary-ip> <primary-ip> "config-id";
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 TCPWARE directory on both the Primary and the Secondary systems.
Note! Make sure the name of the configuration file matches the config-id parameter in the boot file for that system.
Preferably, the configuration files on the Primary and the Secondary server systems should be the same. To help ensure that the configuration file is valid for both systems, make sure it contains a subnet statement for every subnet that either the Primary or the Secondary system has a network interface on.
7 Make sure that both the Primary and the Secondary systems have lease files in the TCPWARE directory with the name that matches config-id. If the lease file does not exist, create an empty one.
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!
To use Safe-failover, create a boot file at TCPWARE:DHCPD.BOOT. The boot file is used to specify the following for Safe-failover operation:
• 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 tcpware:dhcpd.conf and tcpware:dhcpd.leases for its default configuration and lease files. The server does not use a state file to keep track and remember its state transitions when running in standalone mode (that is, with DHCP Safe-failover disabled). See State File for DHCP Safe-failover for a description of state files. The following server modes are possible:
Table 4-7 DHCP Safe-failover Server Modes
The IP address following the server mode is the server address, the next IP address is the secondary or backup server IP address.
The configuration ID is the file name (without the file type) of the configuration, lease, and state files. For example, if the configuration ID is ALPHA, the DHCP server looks for a configuration file named ALPHA.CONF, a lease file named ALPHA.LEASES, and a state file named ALPHA.STATE.
primary 199.23.24.11 199.23.24.25 "ALPHA";
The example boot file designates the current server as the primary with its own IP address 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";
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:
Table 4-8 DHCP Safe-failover Server States
|
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.
The statements shown in Table 4-9 have been added to the DHCP configuration file for DHCP Safe-failover. These are in addition to the DHCP configuration file statements listed in Table 4-1. All the parameters in Table 4-9 must be placed in the configuration file's global scope, with the exception of the backup-pool-size parameter. It may also be specified within a shared-network or subnet declaration.
Table 4-9 DHCP Safe-failover Configuration File Statements (Continued)
The statements shown in Table 4-10 have been added to the DHCP lease file for DHCP Safe-failover. These are in addition to the DHCP lease file statements listed in Table 4-4.
Table 4-10 DHCP Safe-failover Lease File Statements (Continued)
There are three ways that you can transition the DHCP server to Partner Down state, which indicates that its DHCP Safe-failover partner is down.
1 If the parameter safe-period-timeout is specified in the configuration file, the DHCP server transitions to Partner Down state automatically after it has been in Communication Interrupt state for the specified time.
2 You can put the DHCP server into Partner Down state using the following NETCU command:
$ netcu set dhcp/partnerdown
3 You can edit the DHCP server state file and add a line to the end containing the Partner Down state and transaction number desired. Add either line:
• primary-partnerdown transaction-number;
• backup-partnerdown transaction-number;
The next time the DHCP server is restarted, it will be in Partner Down state. You can restart the DHCP server by shutting down the server with the NETCU STOP/DHCP command. NETCP automatically restarts the DHCP server.
Example 4-2 shows a sample DHCPD.CONF file.
Example 4-2 Sample DHCPD.CONF File
#
# TCPWARE:DHCPD.CONF -- sample DHCP configuration file
#
# option definitions common to all supported networks...
option domain-name "fugue.com";
option domain-name-servers toccato.fugue.com;
default-lease-time 43200;
option subnet-mask 255.255.255.0;
option time-offset 18000;
use-host-decl-names on;
# Shared network declaration is used to group subnets which share the same # physical network together. The name is specified so that the shared # network can be referred to in log messages --
# it serves no other function.
#
# Note: You must have a subnet declaration for the subnet that the DHCP # server system is on even if you don’t want any address pool for the same # subnet (or multiple subnets if the system is multi-homed).
shared-network FUGUE {
# option definitions common to this shared network.
option subnet-mask 255.255.255.224;
default-lease-time 600;
max-lease-time 7200;
# One of the two IP subnets that share this physical network
#
# Address ranges can be specified for each subnet attached to a shared # network. Since these subnets share the same physical network, addresses # are pooled together, and assignments are made without regard to the # actual subnet. If the optional dynamic-bootp keyword is given in the # address range declaration, then addresses in that range can be assigned # either with the DHCP protocol or the BOOTP protocol; otherwise, only # DHCP clients will have addresses allocated from the address range.
#
# Note that each IP subnet can have its own options specific to that # subnet. Options that are not specified in the subnet are taken from the # shared network (if any) and then from the global option list.
subnet 204.254.239.0 netmask 255.255.255.224 {
range 204.254.239.10 204.254.239.20;
option broadcast-address 204.254.239.20;
option routers prelude.fugue.com;
}
# The other subnet that shares this physical network
subnet 204.254.239.32 netmask 255.255.255.224 {
range dynamic-bootp 204.254.239.42 204.254.239.52;
option broadcast-address 204.254.239.31;
option routers snarg.fugue.com;
}
# Subnets can have no pooled ip addresses.
subnet 10.10.10.0 netmask 255.255.255.0 {
}
}
# IP subnets that are alone on their physical wire should be declared by # themselves. The DHCP server still refers to them as shared networks in # log messages, but this is simply an artifact of the underlying data # structure.
#
# Note that options can be specified in the subnet declaration that # supercede the global options specified earlier.
subnet 192.5.5.0 netmask 255.255.255.224 {
range 192.5.5.26 192.5.5.30;
option domain-name-servers bb.home.vix.com, gw.home.vix.com;
option domain-name "vix.com";
option routers 192.5.5.1;
option subnet-mask 255.255.255.224;
option broadcast-address 192.5.5.31;
default-lease-time 600;
max-lease-time 7200;
}
# Hosts that require special configuration options can be listed in host # statements. If no address is specified, the address will be allocated # dynamically (if possible), but the host-specific information will still # come from the host declaration.
host passacaglia {
hardware ethernet 0:0:c0:5d:bd:95;
filename "vmunix.passacaglia";
server-name "toccato.fugue.com";
}
# Fixed IP addresses can also be specified for hosts. These addresses # should not also be listed as being available for dynamic assignment. # Hosts for which fixed IP addresses have been specified can boot using # BOOTP or DHCP. Hosts for which no fixed address is specified can only be # booted with DHCP, unless there is an address range on the subnet to # which a BOOTP client is connected which has the dynamic-bootp flag set.
host fantasia {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address fantasia.fugue.com;
}
# If a DHCP or BOOTP client is mobile and might be connected to a variety # of networks, more than one fixed address for that host can be specified. # Hosts can have fixed addresses on some networks, but receive dynamically # allocated address on other subnets; in order to support this, a host # declaration for that client must be given which does not have a fixed # address. If a client should get different parameters depending on what # subnet it boots on, host declarations for each such network should be # given. Finally, if a domain name is given for a host’s fixed address and # that domain name evaluates to more than one address, the address # corresponding to the network to which the client is attached, if any, # will be assigned.
host confusia {
hardware ethernet 02:03:04:05:06:07;
fixed-address confusia-1.fugue.com, confusia-2.fugue.com;
filename "vmunix.confusia";
server-name "toccato.fugue.com";
}
host confusia {
hardware ethernet 02:03:04:05:06:07;
fixed-address confusia-3.fugue.com;
filename "vmunix.confusia";
server-name "snarg.fugue.com";
}
host confusia {
hardware ethernet 02:03:04:05:06:07;
filename "vmunix.confusia";
server-name "bb.home.vix.com";
}
# Some other examples
host host1 {
option dhcp-client-identifier "host1";
fixed-address 10.10.11.101, 10.11.22.101;
}
# Do not allow this one to boot
host host2
hardware ethernet aa:cc:04:00:33:11;
deny booting;
}
