Before you can set up your network to use DHCP, you must collect information and make decisions about how you will configure the server(s). You must:
Map out your network topology to determine which servers are the best candidates for DHCP servers, and how many servers you will need.
Update your system files and netmasks table to reflect network topology accurately. If your DHCP server is to support clients on remote networks, you must also be sure the netmasks table entries for those networks are up to date. (See netmasks(4) for more information.
Choose the data storage method you will use, local files or NIS+.
Define a lease policy.
Determine how router information should be obtained by clients.
If you have not already done so, you should map out the physical structure or layout of your network, indicating the location of routers and clients, and the location of servers providing network services. This mapping of your network topology can help you determine which server to use for DHCP services, and what configuration information the DHCP server can provide to clients.
See Chapter 5, Planning Your TCP/IP Network for more information about planning your network.
The DHCP configuration process can look up some network information from the server's system and network files. "Updating System Files and Netmask Tables" discusses these files. However, you might want to give clients other service information, which you must enter into the server's databases. As you examine your network topology, record the IP addresses of any servers you want your clients to know about. The following are some examples of network services you may have on your network that the DHCP configuration does not find out about:
Time server
Log server
Print server
Install server
Boot server
Swap server
X window font server
TFTP server
DHCP does not work well in network environments where more than one IP network is sharing the same network hardware media, either through the use of multiple network hardware interfaces or multiple logical interfaces. When multiple IP networks run across the same physical LAN, a DHCP client's request arrives on all network hardware interfaces, making the client appear to be attached to all of the IP networks simultaneously.
DHCP must be able to determine the address of a client's network in order to assign an appropriate IP address to the client. If more than one network is present on the hardware media, the server cannot determine the client's network, and cannot assign an IP address.
You can use DHCP on one of the networks, but not more than one. If this does not suit your needs, you must reconfigure the networks. Suggestions for reconfiguring include:
Use variable length subnet masks (VLSM) to make better use of the IP address space you have, so you do not need to run multiple LANs on the same physical network. See RFC-1519 for more information on VLSM and Classless Inter-Domain Routing (CDIR).
Configure the ports on your switches to assign devices to different physical LANs. This preserves the mapping of one LAN to one IP network required for Solaris DHCP. See the documentation for the switch for information about port configuration.
The data store method you use has a direct effect on the number of servers you must have to support your DHCP clients. If you use the local files method one server can support a maximum of 10,000 clients. If you use NIS+ one server can support a maximum of 40,000 clients.
The section "Choosing the Data Store" discusses data store locations.
During the configuration process, DHCP Manager or the dhcpconfig utility scans various system files on your server for information it can use to configure the server.
You must be sure the information in the system files is current before running DHCP Manager or dhcpconfig to configure your server. If you notice errors after configuring the server, manually change macros on the server to update the dhcptab configuration table.
The following table lists some of the information gathered during DHCP server configuration, and the sources for the information. Be sure this information is set correctly on the server before you configure DHCP on it. If you make changes to the system files after configuring the server, you should rerun DHCP Manager or dhcpconfig to pick up the changes.
Table 9-1 Information for DHCP Configuration|
Information |
Source |
Comments |
|---|---|---|
|
Timezone |
System date, timezone settings |
The date and timezone are initially set during the Solaris install. You can change the date using the date command and change the timezone by editing the /etc/TIMEZONE file, which sets the TZ variable. |
|
DNS parameters |
/etc/resolv.conf |
DHCP server uses /etc/resolv.conf to look up DNS parameters such as DNS domain name and DNS server addresses. See (link to "Setting Up DNS Clients" section of the Solaris Naming Setup and Configuration Guide) for more information about resolv.conf. |
|
NIS+ parameters |
System domain name, nsswitch.conf, NIS+ |
DHCP server uses the domainname command to obtain the domain name of the server machine, the nsswitch.conf file to determine where to look for domain-based information. If the server machine is a NIS or NIS+ client, the DHCP server queries NIS or NIS+ services to get NIS/NIS+ server IP addresses. |
|
Default router |
System routing tables, user prompt |
DHCP server searches the network routing tables to find the default router for clients attached to the local network. For clients not on the same network, DHCP server must obtain the information by prompting the administrator. |
|
Subnet mask |
Network interface, netmasks table |
DHCP server looks to its own network interfaces to determine the netmask and broadcast address for local clients. If the request had been forwarded by a relay agent, the server looks up the subnet mask in the netmasks table on the relay agent's network. |
|
Broadcast address |
Network interface, netmasks table |
For the local network, DHCP server obtains the broadcast address by querying the network interface. For remote networks, the server uses the BOOTP relay agent's IP address and the remote network's netmask to calculate the broadcast address for the network. |