System Administration Guide: IP Services

Making Decisions for DHCP Server Configuration (Task Map)

This section discusses some of the decisions to make before you configure the first DHCP server on your network. Use this task map to identify the decisions you must make.

Task	Description	For Instructions
Select a server for DHCP	Determine if a server meets the system requirements to run the DHCP service.	Selecting a Server for DHCP
Choose a data store	Compare the data store choices to determine the best for your site.	Choosing the Data Store
Set a lease policy	Learn about IP address leases to help you determine appropriate leasing for your site.	Setting a Lease Policy
Select router address or router discovery	Determine whether DHCP clients use a specific router or router discovery	Determining Routers for DHCP Clients

Selecting a Server for DHCP

With your network topology in mind, you can use the following guidelines to select a host on which to set up a DHCP server.

The server must:

Run the Solaris 2.6, Solaris 7, or Solaris 8 operating environment. You must install the Solaris 8 7/01 operating environment or a later version if you need to support a large number of clients.
Be accessible to all the networks that have clients that will use DHCP, either directly on the network or through a BOOTP relay agent.
Be configured to use routing.
Have a correctly configured netmasks table that reflects your network topology.

Choosing the Data Store

You can choose to store the DHCP data in text files, binary files, or the NIS+ directory service. The following table summarizes the features of each type of data store, and recommends the environment to which each is best suited.

Table 8–3 Comparison of Data Stores


Data Store Type	Performance	Maintenance	Sharing	Recommended Environment
Binary files	High performance, high capacity.	Low-maintenance, no database servers required. Contents must be viewed with DHCP Manager or `dhtadm` and `pntadm`. Regular file backups suggested.	Containers cannot be shared among DHCP servers.	Midsize to large environments with many networks with thousands of clients per network. Useful for small to medium ISPs.
NIS+	Moderate performance and capacity, dependent upon NIS+ service's performance and capacity	DHCP server system must be configured as a NIS+ client. Requires NIS+ service maintenance. Contents must be viewed with DHCP Manager or `dhtadm` and `pntadm`. Regular backups with `nisbackup` suggested.	DHCP data is distributed in NIS+, multiple servers can access the same containers.	Small to midsize environments with up to 5000 clients per network.
Text files	Moderate performance, low capacity.	Low-maintanence, no database servers required. ASCII format is readable without DHCP Manager, `dhtadm`, or `pntadm`. Regular file backups suggested.	Containers can be shared among DHCP servers if DHCP data is stored on one file system that is exported though an NFS mount point.	Small environments with a few hundred to a thousand clients per network, less than 10,000 total clients.

Traditional NIS (as opposed to NIS+) is not offered as a data store option because it does not support fast incremental updates. If your network uses NIS, you should use text files or binary files for your data store.

Setting a Lease Policy

A lease specifies the amount of time the DHCP server grants permission to a DHCP client to use a particular IP address. During the initial server configuration, you must specify a site-wide lease policy to indicate the lease time and whether clients can renew their leases. The server uses the information you supply to set option values in the default macros it creates during configuration. You can set different lease policies for specific clients or type of clients, by setting options in configuration macros you create.

The lease time is specified as a number of hours, days, or weeks for which the lease is valid. When a client is assigned an IP address (or renegotiates a lease on an IP address it is already assigned), the lease expiration date and time is calculated by adding the number of hours in the lease time to the timestamp on the client's DHCP acknowledgment. For example, if the timestamp of the DHCP acknowledgment is September 16, 2001 9:15 A.M., and the lease time is 24 hours, the lease expiration time is September 17, 2001 9:15 A.M. The lease expiration time is stored in the client's DHCP network record, viewable in DHCP Manager or with pntadm.

The lease time value should be relatively small, so that expired addresses are reclaimed quickly, but large enough so that if your DHCP service becomes unavailable, the clients continue to function until the system(s) that run the DHCP service can be repaired. A rule of thumb is to specify a time that is two times the predicted down time of a server. For example, if it generally takes four hours to obtain and replace a defective part and reboot the server, you should specify a lease time of eight hours.

The lease negotiation option determines whether or not a client can renegotiate its lease with the server before the lease expires. If lease negotiation is allowed, the client tracks the time that remains in its lease, and when half the lease time is used, the client requests the DHCP server to extend its lease to the original lease time. It is useful to disable lease negotiation in environments where there are more systems than IP addresses, so the time limit is enforced on the use of IP addresses. If there are enough IP addresses, you should enable lease negotiation so you do not force a client to take down its network interface and obtain a new lease, which can interrupt the client's TCP connections (such as NFS and telnet sessions). You can enable lease negotiation site-wide during the server configuration, and for particular clients or types of clients through the use of the LeaseNeg option in configuration macros.

Note –

Systems that provide services on the network should retain their IP addresses, and should not be subject to short-term leases. You can use DHCP with such systems if you assign them reserved (manual) IP addresses, rather than IP addresses with permanent leases. This enables you to detect when the system's IP address is no longer in use.

Determining Routers for DHCP Clients

Clients use routers for any network communication beyond their local network, and they must know the IP addresses of these routers in order to use them.

When you configure a DHCP server, you must provide the IP address of a router the clients can use or, if you use DHCP Manager, you can specify that clients should find routers themselves with the router discovery protocol.

If clients on your network support router discovery, you should use router discovery protocol, even if there is only one router. Discovery enables a client to adapt easily to router changes in the network. For example, if a router fails and is replaced by one with a new address, clients can discover the new address automatically without having to obtain a new network configuration to get the new router address.