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. | |
Choose a data store | Compare the data store choices to determine the best for your site. | |
Set a lease policy | Learn about IP address leases to help you determine appropriate leasing for your site. | |
Select router address or router discovery | Determine whether DHCP clients use a specific router or router discovery |
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.
Making Decisions for IP Address Management (Task Map)
As part of the DHCP service setup, you determine several aspects of the IP addresses that the server is to manage. If your network needs more than one DHCP server, you must decide how to divide responsibility for the addresses so you can assign some to each server. The following task map can help you make IP address management decisions.
Task | Description | Information |
|---|---|---|
Specify what addresses the server should manage | Determine how many addresses you want the DHCP server to manage, and what those addresses are. | |
Decide if server should automatically generate host names for clients | Learn about client host name generation and decide whether to use it. | |
Determine what configuration macro to assign to clients | Learn about client configuration macros so you can select an appropriate macro for clients. | |
Determine lease types to use | Learn about lease types to help you determine what type is best for your DHCP clients |
Number and Ranges of IP Addresses
During the initial server configuration, DHCP Manager allows you to add one block, or range, of IP addresses under DHCP management by specifying the total number of addresses and the first address in the block. DHCP Manager adds a list of contiguous addresses from this information. If you have several blocks of noncontiguous addresses, you can add the others by running DHCP Manager's Address Wizard again, after the initial configuration.
Before you configure your IP addresses, know how many addresses are in the initial block of addresses you want to add and the IP address of the first address in the range.
Client Host Name Generation
The dynamic nature of DHCP means that an IP address is not permanently associated with the host name of the system that is using it. The DHCP management tools can generate a client name to associate with each IP address if you select this option. The client names consist of a prefix, or root name, plus a dash and a number assigned by the server. For example, if the root name is charlie, the client names will be charlie-1, charlie-2, charlie-3, and so on.
By default, generated client names begin with the name of the DHCP server that manages them. This is useful in environments that have more than one DHCP server because you can quickly see in the DHCP network tables which clients any given DHCP server manages. However, you can change the root name to any name you choose.
Before you configure your IP addresses, decide if you want the management tools to generate client names, and if so, what root name to use for the names.
The generated client names can be mapped to IP addresses in /etc/inet/hosts, DNS, or NIS+ if you specify this at configuration. See "Client Host Name Registration" for more information.
Default Client Configuration Macros
In Solaris DHCP, a macro is a collection of network configuration options and their assigned values. The DHCP server uses macros to determine what network configuration information to send to a DHCP client.
When you configure the DHCP server, the management tools gather information from system files and directly from you through prompts or command-line options you specify. With this information, the management tools create the following macros:
Network address macro, named to match the IP address of the client network. The macro contains information needed by any client that is part of the network, such as subnet mask, network broadcast address, default router or router discovery token, and NIS/NIS+ domain and server if the server uses NIS/NIS+. Other options applicable to your network might be included.
Locale macro, named Locale. The macro contains the offset (in seconds) from Universal Time to specify the time zone.
Server macro, named to match the server's host name. The macro contains information about the lease policy, time server, DNS domain, and DNS server, and possibly other information that the configuration program was able to obtain from system files. This macro includes the Locale macro.
The network address macro is automatically processed for all clients located on that network. The locale macro is included in the server macro, so it is processed when the server macro is processed.
When you configure IP addresses for the first network, you must select a client configuration macro to be used for all DHCP clients using the addresses you are configuring. By default, the server macro is selected because it is contains information needed by all clients that use this server. Clients receive the options contained in the network address macro before those in the server macro. See "Order of Macro Processing" for more information about the order in which macros are processed.
Dynamic and Permanent Lease Type
The lease type determines if the lease policy applies to the addresses you are configuring. During initial server configuration, DHCP Manager allows you to select either dynamic or permanent leases for the addresses you are adding. If you configure with the dhcpconfig command, leases are dynamic.
When an address has a dynamic lease, the DHCP server can manage the address by allocating it to a client, extending the lease time, detecting when it is no longer in use, and reclaiming it. When an address has a permanent lease, the DHCP server can only allocate it to a client, after which the client owns the address until the client explicitly releases it. When the address is released, the server can assign it to another client. The address is not subject to the lease policy as long as it is configured with a permanent lease type.
When you configure a range of IP addresses, the lease type you select applies to all the addresses in the range. To get the most benefit from DHCP, you should use dynamic leases for most of the addresses. You can later modify individual addresses to make them permanent if necessary, but the total number of permanent leases should be kept to a minimum.