DHCP Client Management
The Solaris DHCP client does not require management under normal system operation. It automatically starts when the system boots, renegotiates leases, and stops when the system shuts down. You cannot manually start and stop the dhcpagent daemon. However, you can use the ifconfig command as superuser on the client system to affect the client's management of the network interface if necessary.
ifconfig Command Options Used With DHCP Client
The ifconfig command enables you to:
Start the DHCP client - The command ifconfig interface dhcp start initiates the interaction between the DHCP client and DHCP server to obtain an IP address and a new set of configuration options. This might be useful when you change information that you want a client to use immediately, such as when you add IP addresses or change the subnet mask.
Request network configuration information only - The command ifconfig interface dhcp inform causes dhcpagent to issue a request for network configuration parameters, with the exception of the IP address. This is useful for situations where the network interface has a valid IP address, but the client system needs updated network options. For example, this might be useful if you do not use DHCP to manage IP addresses, but do use it to configure hosts on the network.
Request a lease extension - The command ifconfig interface dhcp extend causes dhcpagent to issue a request to renew the lease. This happens automatically, but you might want to use this command if you change the lease time and want clients to use the new lease time immediately rather than waiting for the next attempt at lease renewal.
Release the IP address - The command ifconfig interface dhcp release causes dhcpagent to relinquish the IP address used by the network interface. This happens automatically when the lease expires. You might want to issue this command if the lease time is long and you need to take down the network interface for an extended period of time or you want to remove the system from the network.
Drop the IP address - The command ifconfig interface dhcp drop causes dhcpagent to take down the network interface without informing the DHCP server that it is doing so. This enables the client to use the same IP address when it reboots.
Ping the network interface - The command ifconfig interface dhcp ping lets you test to see if the interface is under the control of DHCP.
View DHCP configuration status of the network interface - The command ifconfig interface dhcp status displays the current state of the DHCP client. The display indicates the following:
If an IP address has been bound to the client
Number of requests sent, received, and declined
If this is the primary interface
Times when the lease was obtained, when it expires, and when attempts to renew it will or did start
# ifconfig hme0 dhcp status Interface State Sent Recv Declined Flags hme0 BOUND 1 1 0 [PRIMARY] (Began,Expires,Renew)=(08/16/2000 15:27, 08/18/2000 13:31, 08/17/2000 15:24)
DHCP Client Parameter File
The file /etc/default/dhcpagent on the client system contains tunable parameters for the dhcpagent daemon. You can use a text editor to change several parameters that affect client operation. The file is well documented so you should refer to the file for more information, as well as referring to the dhcpagent man page.
DHCP Client Shutdown
When the system running the DHCP client shuts down normally, the dhcpagent daemon writes the current configuration information to the file /etc/dhcp/interface.dhc. The lease is dropped rather than released, so the DHCP server does not know that the IP address is not in active use.
If the lease is still valid when the system reboots, the DHCP client sends an abbreviated request to use the same IP address and network configuration information it had used before the system rebooted. If the DHCP server permits this, the client can use the information that it wrote to disk when the system shut down. If the server does not permit the client to use the information, the client initiates the DHCP protocol sequence described previously and obtains new network configuration information.
DHCP Client Systems and Name Services
Solaris systems support the following name services: DNS, NIS, NIS+, and a local file store (/etc/hosts). Each name service requires some configuration before it is usable. The name service switch configuration file (see nsswitch.conf(4)) must also be set up appropriately to indicate the name services to be used.
Before a DHCP client system can use a name service, you must configure the system as a client of the name service.
The following table summarizes issues related to each name service and DHCP, and includes links to documentation that can help you set up clients for each name service.
Table 7-4 Name Service Client Setup Information for DHCP Client Systems
Name Service | Client Setup Notes |
|---|---|
NIS | If you are installing the Solaris operating environment on a client system by using Solaris DHCP, you can use a configuration macro that contains the NISservs and NISdmain options to pass the IP addresses of NIS servers and the NIS domain name to the client. The client then automatically becomes a NIS client. If a DHCP client system is already running the Solaris operating environment, the NIS client is not automatically configured on that system when the DHCP server sends NIS information to the client. If the DHCP server is configured to send NIS information to the DHCP client system, you can see the values given to the client if you use the dhcpinfo command on the client as follows: # /sbin/dhcpinfo NISdmain # /sbin/dhcpinfo NISservs Use the values returned for the NIS domain name and NIS servers when you set up the system as a NIS client. You set up a NIS client for a Solaris DHCP client system in the standard way, as documented in "Setting Up and Configuring NIS Service" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Note - You can write a script that uses dhcpinfo and ypinit to automate NIS client configuration on DHCP client systems. |
NIS+ | If the DHCP client system receives a nonreserved IP address (the address may not always be the same), you must set up the NIS+ client for a DHCP client system in a nonstandard way, which is documented in "Setting Up DHCP Clients as NIS+ Clients". This procedure is necessary because NIS+ uses security measures to authenticate requests for service. The security measures depend upon the IP address. If the DHCP client system has been manually assigned an IP address (the client's address is always the same), you can set up the NIS+ client in the standard way, which is documented in "Setting Up NIS+ Client Machines" in System Administration Guide: Naming and Directory Services (FNS and NIS+) |
/etc/inet/hosts | You must set up the /etc/inet/hosts file for a DHCP client system that is to use /etc/inet/hosts for its name service. The DHCP client system's host name is added to its own /etc/inet/hosts file by the DHCP tools. However, you must add the host name manually to the /etc/inet/hosts files of other systems in the network. If the DHCP server system uses /etc/inet/hosts for name resolution, you must also add the client's host name manually on the system. |
DNS | If the DHCP client system receives the DNS domain name through DHCP, the client system's /etc/resolv.conf file is configured automatically. To actually use DNS on systems that use /etc/inet/hosts files, you must modify the /etc/nsswitch.conf file to add dns to the hosts line. See "Setting Up a DNS Client" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information about DNS clients. If the client system uses NIS or NIS+ for local name resolution, you should be aware of the following:
|
Client Host Name Registration
If you let the DHCP server generate host names for the IP addresses you place in the DHCP service, the DHCP server can register those host names in NIS+, /etc/inet/hosts, or DNS name services. Host name registration cannot be done in NIS because NIS does not provide a protocol to allow programs to update and propagate NIS maps.
Note - The DHCP server can update DNS with generated host names only if the DNS server and DHCP server are running on the same system.
If a DHCP client provides its host name and the DNS server is configured to allow dynamic updates from the DHCP server, the DHCP server can update DNS on the client's behalf, even if the DNS and DHCP servers are running on different systems. See "Enabling Dynamic DNS Updates by DHCP Server" for more information about enabling this feature.
The following table summarizes client host name registration for DHCP client systems with the various name services.
Table 7-5 Client Host Name Registration in Name Services
| Who Registers Host Name | |
|---|---|---|
Name Service | DHCP Generated Host Name | DHCP Client Supplied Host Name |
NIS | NIS Administrator | NIS Administrator |
NIS+ | DHCP tools | DHCP tools |
/etc/hosts | DHCP tools | DHCP tools |
DNS | DHCP tools, if the DNS server runs on the same system as the DHCP server. DNS Administrator, if the DNS sever runs on a different system. | DHCP server, if configured for dynamic DNS updates. DNS Administrator, if DHCP server is not so configured. |
Note that Solaris DHCP clients can request particular host names in DHCP requests if configured to do so as described in "How to Enable a Solaris Client to Request Specific Host Name". Please consult the documentation for non-Solaris clients to determine if the capability is supported.
DHCP Client Systems With Multiple Network Interfaces
The DHCP client daemon can manage several different interfaces on one system simultaneously, each with its own IP address and lease time. If more than one network interface is configured for DHCP, the client issues separate requests to configure them and maintains a separate set of network configuration options for each interface. However, although the parameters are stored separately, some of the parameters are global in nature, applying to the system as a whole, rather than to a particular network interface.
Options such as hostname, NIS domain name, and timezone are global parameters and should have the same values for each interface, but these values may differ due to errors in the information entered by the DHCP administrator. To ensure that there is only one answer to a query for a global parameter, only the parameters for the primary network interface are requested. You can insert the word primary in the /etc/dhcp.interface file for the interface you want to be treated as the primary interface.