JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: IP Services     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


Part I Introducing System Administration: IP Services

1.  Oracle Solaris TCP/IP Protocol Suite (Overview)

Part II TCP/IP Administration

2.  Planning Your TCP/IP Network (Tasks)

3.  Introducing IPv6 (Overview)

4.  Planning an IPv6 Network (Tasks)

5.  Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

6.  Administering Network Interfaces (Tasks)

7.  Configuring an IPv6 Network (Tasks)

8.  Administering a TCP/IP Network (Tasks)

9.  Troubleshooting Network Problems (Tasks)

10.  TCP/IP and IPv4 in Depth (Reference)

11.  IPv6 in Depth (Reference)


12.  About DHCP (Overview)

13.  Planning for DHCP Service (Tasks)

Preparing Your Network for the DHCP Service (Task Map)

Mapping Your Network Topology

Network Topology to Avoid

Determining the Number of DHCP Servers

Updating System Files and Netmask Tables

Making Decisions for Your DHCP Server Configuration (Task Map)

Selecting a Host to Run the DHCP Service

Choosing the DHCP Data Store

Setting a Lease Policy

Determining Routers for DHCP Clients

Making Decisions for IP Address Management (Task Map)

Number and Ranges of IP Addresses

Client Host Name Generation

Default Client Configuration Macros

Dynamic and Permanent Lease Types

Reserved IP Addresses and Lease Type

Planning for Multiple DHCP Servers

Planning DHCP Configuration of Your Remote Networks

Selecting the Tool for Configuring DHCP

DHCP Manager Features

dhcpconfig Features

Comparison of DHCP Manager and dhcpconfig

14.  Configuring the DHCP Service (Tasks)

15.  Administering DHCP (Tasks)

16.  Configuring and Administering the DHCP Client

17.  Troubleshooting DHCP (Reference)

18.  DHCP Commands and Files (Reference)

Part IV IP Security

19.  IP Security Architecture (Overview)

20.  Configuring IPsec (Tasks)

21.  IP Security Architecture (Reference)

22.  Internet Key Exchange (Overview)

23.  Configuring IKE (Tasks)

24.  Internet Key Exchange (Reference)

25.  IP Filter in Oracle Solaris (Overview)

26.  IP Filter (Tasks)


27.  Introducing IPMP (Overview)

28.  Administering IPMP (Tasks)

Part VI IP Quality of Service (IPQoS)

29.  Introducing IPQoS (Overview)

30.  Planning for an IPQoS-Enabled Network (Tasks)

31.  Creating the IPQoS Configuration File (Tasks)

32.  Starting and Maintaining IPQoS (Tasks)

33.  Using Flow Accounting and Statistics Gathering (Tasks)

34.  IPQoS in Detail (Reference)



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. The following table guides you in the decisions you need to configure your network to use DHCP, and links each task to the section that describes the steps to perform each task.

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 types to determine the best data store for your site.
Set a lease policy.
Learn about IP address leases to help you determine appropriate lease policy for your site.
Select a router address or router discovery.
Determine whether DHCP clients use router discovery or a specific router.

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:

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
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.
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.