Making Decisions for Your 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 that you must make.
Selecting a Host to Run the DHCP Service
With your network topology in mind, you can use the following system requirements
to select a host on which to set up a DHCP server.
The host must meet the following requirements:
The host must run the Solaris 2.6 release or later. If you need to support a large number of clients, you must install the Solaris 8 7/01 release or a later version.
The host must be accessible to all the networks that have clients that plan to use DHCP, either directly on the network or through a BOOTP relay agent.
The host must be configured to use routing.
The host must have a correctly configured netmasks table that reflects your network topology.
Choosing the DHCP 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 indicates the environment in which to use each
data store type.
Table 13-3 Comparison of DHCP Data Stores
Data Store Type |
Performance |
Maintenance |
Sharing |
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. |
Data stores 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 an NIS+ client. Requires NIS+ service
maintenance. Contents must be viewed with DHCP Manager or dhtadm and pntadm.
Regular backup with nisbackup is suggested. |
DHCP data is distributed in NIS+, and 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 maintenance, no database servers required.
ASCII format is readable without DHCP Manager, dhtadm, or pntadm. Regular file backups suggested. |
Data
store can be shared among DHCP servers if DHCP data is stored
on one file system that is exported through an NFS mount point. |
Small environments
with less than 10,000 clients, with a few hundred to a thousand clients
per network. |
Traditional NIS is not offered as a data store option because NIS
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 permits a DHCP
client to use a particular IP address. During the initial server configuration, you
must specify a site-wide lease policy. The lease policy indicates the lease time
and specifies whether clients can renew their leases. The server uses the information
that you supply to set option values in the default macros that the
server 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, the lease expiration date and
time is calculated. The number of hours in the lease time is
added to the timestamp on the client's DHCP acknowledgement. For example, suppose the timestamp
of the DHCP acknowledgment is September 16, 2005 9:15 A.M., and the lease
time is 24 hours. The lease expiration time in this example is September
17, 2005 9:15 A.M. The lease expiration time is stored in the client's
DHCP network record, viewable in DHCP Manager or with the pntadmutility.
The lease time value should be relatively small so that expired addresses are
reclaimed quickly. The lease time value also should be large enough to outlast
DHCP service disruptions. Clients should be able to function while the system that
runs the DHCP service is repaired. A general guideline is to specify a
time that is two times the predicted downtime of a system. For example,
if you need four hours to obtain and replace a defective part
and reboot the system, specify a lease time of eight hours.
The lease negotiation option determines whether 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. When half of the lease
time has passed, the client requests the DHCP server to extend its lease
to the original lease time. You should disable lease negotiation in environments where
there are more systems than IP addresses. The time limit is then enforced
on the use of IP addresses. If there are enough IP addresses, you
should enable lease negotiation to avoid forcing clients to take down their network
interfaces when leases expire. If you make clients obtain new leases, the clients'
TCP connections such as NFS and telnet sessions might be interrupted. You can
enable lease negotiation for all clients during the server configuration. You can enable
lease negotiation for particular clients or particular 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. Such
systems should not be subject to short-term leases. You can use DHCP with
such systems if you assign reserved manual IP addresses to those systems, rather
than IP addresses with permanent leases. You can then detect when the system's
IP address is no longer in use.
Determining Routers for DHCP Clients
Host systems use routers for any network communication beyond their local network. The
hosts must know the IP addresses of these routers.
When you configure a DHCP server, you must provide DHCP clients with router
addresses in one of two ways. One way is to provide specific
IP addresses for routers. However, the preferred method is to specify that clients
should find routers with the router discovery protocol.
If clients on your network can perform router discovery, you should use the
router discovery protocol, even if there is only one router. Router discovery enables
a client to adapt easily to router changes in the network. For example,
suppose that a router fails and is replaced by a router 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.
