This section discusses some of the decisions to make before configuring the first DHCP server on your network. The topics parallel the dialogs in the DHCP Manager's Configuration Wizard, but the information is also useful if you decide to use the dhcpconfig utility to configure the server.
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
Be accessible to all the networks having 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
You can choose to store the DHCP data using files in a local directory or NIS+ tables in a NIS+ directory service. Because NIS+ is distributed, multiple servers can access the same database. NIS+ also provides inherently faster information retrieval. Note that the server machine must already be configured as a NIS+ client to use this option.
The files method can be used efficiently at sites having less than 10,000 DHCP clients, but it is somewhat slower than NIS+, and requires all DHCP data to be stored on one file system. The data stored in files can only be shared with multiple DHCP servers if it is exported through an NFS mount point.
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 files for your data store.
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, indicating 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, 1999 9:15 A.M., and the lease time is 24 hours, the lease expiration time is September 17, 1999 9:15 A.M. The lease expiration time is stored in the client's DHCP network record, viewable in the DHCP Manager or using 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 machine(s) running 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 remaining 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. Disallowing lease negotiation is useful for environments where there are more machines than IP addresses, so the time limit is enforced on the use of IP addresses. If there are enough IP addresses, lease negotiation should be permitted to avoid forcing a client to take down its network interface and obtain a new lease, possibly interrupting their TCP connections (such as NFS and telnet sessions). Lease negotiation can be set site-wide during the server configuration, and for particular clients or types of clients through the use of the LeaseNeg option in configuration macros.
Systems providing services on the network should retain their IP addresses, and should not be subject to short-term leases. You can use DHCP with such machines by assigning them reserved (manual) IP addresses, rather than IP addresses with permanent leases. This enables you to detect when the machine's IP address is no longer being used.
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.
During DHCP server configuration, 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 by using the router discovery protocol.
If clients on your network support router discovery, you should use router discovery protocol instead of specifying the IP address, 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.