TCP/IP and Data Communications Administration Guide

Part IV Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) allows a host to get an Internet Protocol (IP) address and other Internet configuration parameters without any need for preconfiguration by the user. This new protocol improves on the traditional Internet architecture, where the system administrator must assign or change each IP address individually.

DHCP reduces the cost of managing networks by eliminating the need for the administrator to assign or change addresses again and again.

Chapter 14 Understanding DHCP

This chapter introduces the Dynamic Host Configuration Protocol (DHCP) and describes both the client and server sides of the protocol. It discusses Bootstrap Protocol (BOOTP) relay agents, which can be used in the operation of DHCP.

What is DHCP?

DHCP provides a host with an Internet Protocol (IP) address and other Internet configuration parameters without any need for preconfiguration by the user. This new protocol improves on the traditional Internet architecture, where the system administrator must assign or change each IP address individually. The manual process is expensive, difficult, error-prone and time-consuming.

DHCP reduces the cost of managing networks by eliminating the need for the administrator to assign or change IP addresses again and again. Dynamic IP addresses are chosen from a pool of unused IP addresses, and are automatically assigned to a host for temporary or permanent use. DHCP also reclaims that IP address for use by other clients when it is no longer needed or when the time period for its use is up.

The packet formats for DHCP and BOOTP are the same, although BOOTP packets are fixed length and DHCP packets are variable length. The DHCP packet length is negotiated between the client and the server.

The Dynamic Host Configuration working group of the Internet Engineering Task Force (IETF) has been working for approximately five years on the problems presented by the current IP address assignment architecture. The IETF is in the process of standardizing DHCP. It currently has the status of several Requests For Comment (RFCs), including RFCs 1542, 2131, and 2132.

The Internet has grown so rapidly that users are running out of network addresses to support it. In response to this problem, Classless Inter-Domain Routing (CIDR) was developed. IP addresses had been separated into class A, B, and C for large, medium, and small networks. As the class B IP addresses were depleted, the CIDR design came into use. CIDR was based on the idea that an organization should get the exact number of class C IP addresses it needs, rather than be assigned one class B network, consisting of 65,536 addresses.

The class C network numbers allocated following the CIDR strategy are not random. They are contiguous and share the same prefixes. This helps alleviate many of the problems caused by manipulating very large routing tables.

With the CIDR strategy, blocks of IP addresses are allocated to individual ISPs, not to individual requestors or companies, as was previously the case. So it becomes important to renumber easily, in order to change ISPs easily. DHCP makes it easy to renumber networks, and therefore easier to change ISPs.

DHCP is a technology that enables several useful features, including:

Automatic network configuration, such that after client machines are powered up on a network that supports DHCP, the clients acquire what they need. For example, their IP addresses, default routers, subnet masks, the DNS domain, DNS servers, NIS+ domain, NIS+ servers, Timezones, time servers, and all the other information necessary to operate without any need for individual configuration by an administrator.
Automatic IP address management, including assignment, reclamation, reconfiguration, and renumbering of IP addresses. Since all TCP/IP parameters are managed centrally, and the DHCP service manages the assignment and reuse of IP addresses automatically, minimal administrator involvement is necessary.
Vastly simplified system administration through the centralized location of network configuration information. The TCP/IP configuration information can be stored in a central place, instead of being distributed among all the clients in the network. A network can be renumbered simply and quickly, usually in only a few days, using relatively short IP address leases.

DHCP can also exploit existing BOOTP relay functionality since DHCP is based on the BOOTP. This permits network administrators to configure their routers to forward BOOTP/DHCP traffic to remote BOOTP/DHCP servers. Therefore, network parameter servers are no longer needed on every network segment, as was true of the in,rarpd (see in.rarpd(1M)) and bootparams configuration services.

A network administrator can use the command to quickly and easily configure DHCP and BOOTP services on a Solaris 2 server. The command bootstraps the DHCP service and configures local and remote networks. Local networks are those to which the server is directly connected. Remote networks are those to which the server is not directly connected, but are accessed through BOOTP relay agents.

Serving clients on remote networks requires the configuration of a BOOTP relay agent on the client's network. BOOTP relay agent functionality is present in many popular routers and switches. If your router does not support this feature, you can run the in.dhcpd daemon (see in.dhcpd(1M)) in relay agent mode on any Solaris 2 machine on the client's network capable of running in.dhcpd. This is true for machines running Solaris 2.6 and later releases. Figure 14-1 shows an overview of DHCP and BOOTP.

Figure 14-1 DHCP Architectural Diagram

The DHCP Client

The DHCP protocol has two functions with regard to the client. It delivers sufficient information to clients for them to establish an endpoint for network communications, and it supplies other parameters needed by system- and application-level software.

Delivering Client Information

To perform the first function, the DHCP protocol supplies an IP address valid for the network attached to the client's hardware interface. The right to use this IP address is given to the client for a finite period of time, called a lease. This differs from the traditional static configuration. If the client wants to use the IP address for a period of time longer than the original lease, it must periodically negotiate a lease extension with the server through DHCP. When the client no longer needs the IP address, the user of the machine can relinquish its lease, returning it to the pool of available IP addresses. Otherwise, the IP address is reclaimed automatically when its lease expires.

The implementation of the client side of the DHCP protocol on Solaris must meet several criteria. Bootstrapping a Sun workstation is a complex process because of the number and diversity of services that must be configured and invoked. Any DHCP solution must co-exist with other methods already in use, particularly the Reverse Address Resolution Protocol (RARP) and static configuration. It must know that the superuser can change the address of a network interface after the workstation has booted. It must be able to configure multiple interfaces. And it must respond to human control and be able to report on the status and provide the statistics of the protocol.

The Solaris 2 DHCP client meets these criteria by implementing several features. Since leases must be renewed days or weeks after the initial boot, an agent responsible for DHCP on the client must run as a daemon. This daemon, the DHCP agent or dhcpagent (see dhcpagent(1M)) is responsible for all the interactions of the protocol. It sends and receives all the DHCP protocol packets when talking to the server. The daemon:

Constructs and sends packets
Listens for responses from servers
Caches the configuration information received
Releases or renews leases
Configures the interfaces with sufficient information to enable communications with the network through the interface

This is where the responsibilities of the agent end. The daemon knows nothing of any higher-level services that the client might be running.

When the agent starts, it assumes nothing about which interfaces are to be configured by DHCP. It waits for instructions from some other entity. These instructions are passed to the agent by a control protocol, which also returns status and other information from the agent to the controller. The controller allows the user to control the behavior of the agent, and implements this control through new features of the ifconfig(1M) command.

The ifconfig command has new command line options specific to DHCP, which start or terminate DHCP on an interface. After DHCP is started on an interface, the agent sends packets to and receives them from a server as the protocol dictates.

In the simplest example, the interface is successfully configured by DHCP. The agent notes the duration of the lease, informs ifconfig that the interface was configured, writes the configuration it received to disk, and goes back to sleep.

At some predetermined future time, usually 50 percent into the lease's lifetime, the agent reawakens and negotiates an extension to the lease. This renegotiation can occur an unlimited number of times while the workstation is running. Eventually, the system is halted. At that time, ifconfig can tell the agent to relinquish the lease. If the lease is relinquished, the configuration information stored on the disk is removed, since it is no longer valid.

The agent can keep track of leases on many different interfaces simultaneously. There is no requirement that they all be renewed at the same time.

The example above is the simplest one, but circumstances might be more complicated. The agent might not receive any responses to its protocol messages. In that case, the agent can use a configuration previously stored on disk, as long as the lease associated with the configuration has not expired. If no valid configuration is found, the agent can continue to retry DHCP using a predefined retransmission schedule, or it can fail to configure the interface. What it does depends on whether the interface was designated as a primary interface. If it was designated as a primary interface, the agent continues to retry DHCP. If it was not designated as a primary interface, the agent fails the ifconfig command.

In addition, the agent must take into account that human intervention might have occurred. If the agent awakens to discover that the IP address and interface status no longer conform to the DHCP configuration received, then the agent drops the interface from its active list. No further DHCP operations will occur on it until the agent is again asked to acquire a lease for the interface.

Supplying Additional Information

To perform its second function, delivering application and system-level information, the Solaris DHCP client uses another program, dhcpinfo(1). Since the agent does not know about these services, any configuration information it receives via the DHCP protocol is stored, waiting to be retrieved by dhcpinfo.

The dhcpinfo command takes a command line argument with a specified parameter, interrogates the agent as to the value of that parameter, and echoes the result to its standard output as a (human readable) text string. However, the chief consumer of the dhcpinfo answers is not the user, but the Solaris 2 startup scripts, since the output lends itself easily to shell command substitution and output redirection.

Data supplied by DHCP can be host-wide or interface-specific. On a client with a single DHCP-configurable interface, this distinction is meaningless. But on a host with many interfaces, questions of interpretation arise regarding dhcpinfo parameters. For example, the agent could configure two interfaces and find that the NIS+ domain name returned for the two differs. This situation is resolved by dividing interfaces into two categories: the primary interface and secondary interfaces.

The primary interface is the preferred one for a host-wide configuration. When dhcpinfo is asked for a value, it consults the primary interface. It does the same in the case of interface-specific data. The values returned are those that were received on the primary interface. For example, if dhcpinfo is asked for the IP address, it echoes the IP address of the primary interface to standard output. An interface is designated as primary by command line arguments to ifconfig.

The dhcpinfo command allows other command line options to override this default behavior. One of these options allows an interface name to be explicitly specified. In that case, the values returned are those delivered by DHCP for that interface.

Because much of the host-wide data is critically important to successful booting of a Solaris 2 client, the designation of an interface as primary implies that the system cannot boot unless the agent can configure that interface. The ifconfig command is instructed by command line arguments to wait indefinitely until dhcpagent has finished configuring the primary interface.

DHCP Server

The DHCP server manages the IP address space of networks directly connected to that server. To extend this environment into other networks, DHCP servers or BOOTP relay agents must be set up on those networks.

A DHCP server can act as a primary or a secondary server. To be a primary server, it must have a range of IP addresses for which it is responsible.

Note -

The term primary is used differently for the client and the server.

When a DHCP server is added to a network that already has a primary DHCP server, the new server can be configured to provide primary and secondary service, or secondary service only. If the server is configured for both services, both servers can perform the duties of a primary server, (they can give out IP addresses) as long as each is primarily responsible for a different IP range. Each server can act as a secondary server for the other, by confirming existing configurations supplied by a primary server when the primary server is unable to respond to requests for confirmation. Every primary server automatically acts as a secondary server.

A DHCP server's range of IP addresses is specified during the installation and configuration of the software on the server. As a primary DHCP server, the server can give out an IP address to a client requesting a new configuration from the range of IP addresses for which it is responsible. When a client asks for confirmation of its existing configuration, the server responsible for that client's IP address confirms the configuration. Acting as a secondary server, it can confirm configurations that were supplied by another DHCP server on the network.

To provide secondary service, the DHCP server confirms configurations that were supplied by another DHCP server on the network. It does this when the primary server responsible for those IP addresses cannot respond. After a waiting period, the secondary server responds in its place.

DHCP servers can be configured as secondary only. If you decide you want to configure a DHCP server as a secondary server only, you can do this through the dhcpconfig program, by choosing to configure the server without a range of IP addresses that it can give out to clients requesting a new configuration. In this configuration, the DHCP servers should be using NIS+ for their data storage.

DHCP service is enabled and configured on the machine on which it is run with the dhcpconfig utility. This utility allows you to set startup options, configure the DHCP service database type and location, and initialize the dhcptab and dhcp_network tables for any locally attached or remote networks.

When dhcpconfig is invoked, it presents a menu offering the option of configuring the DHCP service, configuring a BOOTP relay agent, removing the DHCP configuration or relay service configuration, or exiting. When the administrator selects one of the menu options, he or she is presented with a series of questions to collect the required information. Then dhcpconfig performs the appropriate steps to turn on the selected functions.

Multiple DHCP servers on the same network operate much more efficiently if they share DHCP databases through NIS+ or NFS. Sharing allows DHCP servers to communicate through a common datastore, increasing redundancy and balancing load among cooperating servers.

When a new DHCP client is added to the network, the client broadcasts a message intended to locate all available DHCP and/or BOOTP servers within reach. Any DHCP server that receives the message first checks to see if any IP addresses are available for assignment. If they are, the server verifies that a potential IP address is not already in use. If it is not, the server offers the IP address and other configuration information to the client. If the IP address is in use, the server marks this IP address as unusable, notifies the network administrator of its status, and selects another IP address.

The client selects an IP address offered to it based on its own criteria, and broadcasts a message that identifies its selection.

Server Databases

The DHCP/BOOTP server uses two types of databases: the dhcptab database and the dhcp_network databases (see dhcp_network(4).

The dhcptab database contains macros defined using a termcap-like syntax. This syntax permits network administrators to define groups of DHCP configuration parameters to be returned to clients. There are currently 77 predefined parameters.

A DHCP/BOOTP server returns hostname, network broadcast address, network subnet mask, or IP maximum transfer unit (MTU), if this information is requested by a client attached to the same network as the server. This information does not have to be explicitly configured in the dhcptab. The dhtadm command manages the dhcptab service configuration table.

If there are two servers sharing a distributed dhcptab table, the administrator can configure the DHCP parameters in the table so the servers back each other up, provided that they are in the same NIS+ domain. However, each should be primarily responsible for a different range of IP addresses. Each network might require a BOOTP relay agent as well, so its clients can reach the server on the other network.

The dhcp_network databases contain client identifier-to-IP address mappings. These databases are named after the network they support. There is one dhcp_network database for each network that offers DHCP/BOOTP services. The dhcp_network databases are located dynamically by the server and consulted during runtime. A client request received from a network for which no dhcp_network database exists is ignored.

The dhcp_network database maps a DHCP client's client identifier to an IP address and the configuration parameter associated with that IP address. This database is located by the DHCP server at runtime by generating a dhcp_network database name by using the IP network address and subnet mask for the network where the DHCP request originated. For example, a dhcp_network database that supports the 10.0.0.0 network would be called 10_0_0_0. The dhcp_network databases can exist as NIS+ tables or ASCII files. Use the pntadm command to manage the dhcp_network databases.

The in.dhcpd daemon has two run modes, DHCP server (with optional BOOTP compatibility mode) and BOOTP relay agent mode (see in.dhcpd(1M).

BOOTP Relay Agents

Multiple networks, and the use of netmasks to identify them, complicate the functioning of TCP/IP-based networks. For instance, broadcasting using IP cannot take place through the gateways that link networks. So clients on one network cannot broadcast DHCP or BOOTP requests to servers on other networks. A BOOTP relay agent must direct the initial requests through the gateway to the server, then return the replies from the server to the clients.

If your router doesn't have a built-in BOOTP relay agent, and you want clients in other networks to have the advantage of the services installed on the DHCP server, you can install BOOTP relay agents on those networks. This allows clients to access DHCP servers from a network that is not running a DHCP server.

The in.dhcpd daemon can be run as a BOOTP relay agent. If you specify BOOTP relay agent mode, the option argument specifies a comma-separated list of IP addresses or the hostnames of DHCP or BOOTP servers to which the relay agent must forward BOOTP requests. When the daemon is started in this mode, any DHCP databases are ignored, and the daemon acts as a BOOTP relay agent.

A BOOTP relay agent listens to UDP port 68, and forwards BOOTP request packets received on this port to the destinations specified on the command line. The relay agent can run on any machine that has knowledge of local routers, so it does not have to be an Internet gateway machine.

The -r IPaddr | hostname ... option enables the BOOTP relay agent. The proper entries need to be made to the netmasks database so that the DHCP server served by the BOOTP relay agents can identify the subnet mask of the foreign BOOTP/DHCP client's network.

After you install the BOOTP relay agent, entries must be added to the distributed DHCP databases so the DHCP servers can service clients sending requests through the BOOTP relay agent.

The macro option (-M) for PNTADM command is a mechanism that permits the network administrator to select configuration parameters to be returned to clients using a particular IP address. It can also be used to deliver a macro with server-specific information by including this macro definition in all dhcp_network database entries owned by a specific server.

Leases

The DHCP/BOOTP server calculates a client's IP address lease using information contained in the dhcptab and dhcp_network databases. The server consults the LeaseTim and LeaseNeg symbols in the dhcptab database, and the Flags and Lease fields of the chosen dhcp_network database record.

The server first examines the Flags field for the identified dhcp_network record. If the PERMANENT or BOOTP flag is on, then the client's lease is considered permanent.

If the PERMANENT flag is not on, then the server checks to see if the client's lease, as represented by the Lease field in the dhcp_network record, has expired. If it has not, the server checks to see if the client has requested a new lease. If the LeaseNeg symbol has not been included in the client's dhcptab parameters, then the client's requested lease extension is ignored, and the lease is set to be the time remaining as shown in the Lease field.

If the LeaseNeg symbol has been included, the server extends the client's lease to the value it requested, provided this requested lease is less than or equal to the current time plus the value of the client's LeaseTim dhcptab parameter. If the client's requested lease is greater than policy allows (the policy is the value of LeaseTim), then the client is given a lease equal to the current time, plus the value of LeaseTim. If LeaseTim is not set, then the default LeaseTim value is one hour.

Chapter 15 Moving to DHCP

This chapter discusses the differences between DHCP, BOOTP or RARP protocols. It describes the advantages of DHCP and explains how to migrate to DHCP.

Why Move to DHCP?

A user who is used to BOOTP or RARP might wonder about the differences and advantages of DHCP. The main difference between DHCP and the older protocols is that the older protocols were designed for manual pre-configuration of the host information in a server database, while DHCP allows dynamic allocation of IP addresses and configurations to newly attached hosts.

In addition, DHCP's leasing mechanism permits automatic recovery and reallocation of IP addresses. DHCP is a superset of BOOTP, offering greater flexibility. DHCP builds on BOOTP using the same protocol packet format and mechanisms with certain additions. In this way, DHCP can leverage the BOOTP relay agent functionality already built into routers, and support BOOTP clients directly.

RARP allows a machine to discover its own IP address, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. The disadvantage of RARP is that it doesn't support other parameters, and a server providing it can serve only directly attached networks.

DHCP and BOOTP traffic can utilize BOOTP relay agent functionality built into common routers. This means the network administrator does not have to place a BOOTP service on every network segment.

When administrators try to support manually configured IP addresses, they are faced with a number of difficulties:

There is no way to detect reliably whether an IP address is still in use.
Any time the network topology changes, such as adding a new network IP address, the administrator has to add new IP addresses manually.
Hosts configured on one network and then moved to another are not able to communicate without having their configuration manually changed.

Advantages of DHCP

DHCP servers offer a number of advantages over earlier methods of getting IP addresses. Here are the features a DHCP server can offer.

Automatic management of IP addresses, including the prevention of duplicate IP address problems
Allows support for BOOTP clients, so you can easily transition your networks from BOOTP to DHCP
Allows the administrator to set lease times, even on manually allocated IP addresses.
Allows limiting which MAC addresses are served with dynamic IP addresses
Allows the administrator to configure additional DHCP option types, over and above what is possible with BOOTP
Allows the definition of the pool or pools of IP addresses that can be allocated dynamically. A user might have a server that forces the pool to be a whole subnet or network. The server should not force such a pool to consist of contiguous IP addresses.
Allows the association of two or more dynamic IP address pools on separate IP networks (or subnets). This is the basic support for secondary networks. It allows a router to act as a BOOTP relay for an interface which has more than one IP network or subnet IP address.

Here are some features that are not part of the DHCP server itself, but related to the way it is administered.

Central administration of multiple servers
The ability to make changes while the server is running and leases are being tracked. For example, you can add or take away IP addresses from a pool, or you can modify parameters.
The ability to make global modifications (those that apply to all entries) to parameters, or to make modifications to groups of clients or pools
The maintenance of a lease audit trail, such as a log of the leases granted

DHCP supports four strategies for IP address allocation. These are independent features. A particular server can offer any or none of them.

Manual. The unique client identifier-to-IP address binding has been made by an administrator. Therefore the DHCP service should not reallocate IP addresses of this type to other clients after the lease expires. This type of IP address allocation is useful when the administrator wants a host to maintain the same IP address but still wants to detect when an IP address is no longer being used. An example is a host that provides a service located by the IP address, like mail.
Permanent. The server's administrator creates a configuration for the server that includes only IP addresses, and gives this configuration to clients. After an IP address is associated with a MAC address, the association is permanent unless the server's administrator intervenes. Allocating permanent IP addresses has the drawback that such IP addresses cannot be reclaimed automatically.
Dynamic (through leases with limited duration). The server tracks leases and gives IP addresses to DHCP clients automatically as they become available when leases expire. No interaction is needed by the administrator. This is the preferred IP address type for non-BOOTP clients.
BOOTP. Addresses that are reserved for use by BOOTP clients. This allows an administrator to enter a pool of IP addresses intended only for BOOTP clients.

Migration

Since DHCP is based on BOOTP and the BOOTP packet structure, migrating to DHCP is easy for most sites. Many DHCP servers support both old BOOTP and new DHCP clients.

Since the Solaris 2 DHCP server handles BOOTP queries as well as DHCP queries, a BOOTP client can boot from a DHCP server. If a DHCP client is written to use the answers from a BOOTP server, a DHCP client can boot from a BOOTP server. The TCP/IP stack included with Windows 95 does not have this capability.

Subnets

DHCP client messages are sent to remote servers by BOOTP relay agents, which are often a feature of an IP router. Through the BOOTP relay agent, the DHCP server can tell which subnet a request came from. The BOOTP relay agent records which subnet the message came from in the DHCP message header. Then the DHCP server can use it to determine which network the client is on.

You cannot run a BOOTP server and a DHCP server on the same machine, because they both use the same port number. You can use the Solaris 2 DHCP server to serve BOOTP clients by turning on BOOTP compatibility mode.

With the DHCP protocol, a client that already has a leased or permanent IP address can get another lease on a temporary basis on another subnet. This is helpful for machines that sometimes must be moved from one location to another. This option is available if the server implementation supports such a feature.

Routers

DHCP requires non-volatile storage. This makes the task of DHCP service compatible with servers, but incompatible with dedicated routers. There are a number of server types that can be configured to both relay and serve DHCP, especially all-in-one Internet Gateways designed to be web servers, firewalls, and so forth. But there are no dedicated routers.

The DHCP RFC specifies that DHCP is not intended for use in configuring routers. The reasons are that in maintaining and troubleshooting a router, it is important to know its exact configuration, rather than leaving that to be established automatically, and that you do not want your router's operation to depend on the working of yet another server.

You may be able to configure some types of more general purpose computers or servers to get their IP addresses from DHCP and to act as routers. In addition, there are remote access servers, which are usually not true routers, which use DHCP to get IP addresses to give to their clients.

Chapter 16 Administration of DHCP

This chapter describes how to administer DHCP, including setting up a network running DHCP, determining a lease time policy, and adding BOOTP relay agents. It also talks about the types of databases DHCP uses and how to create macros within certain databases. It discusses the various options that are implemented in or can be added to DHCP.

Collecting Information Before Setting Up a DHCP Service

To set up a network running DHCP, you must first collect information about your existing network. This includes information about its topology, such as routers, switches, other networks, and services such as name services, file and print services, and so on.

If you plan to support clients on remote networks (clients on a different network from the networks on which you plan to deploy your DHCP services), you must also collect the remote networks' subnet masks, providing the remote network is subnetted. Be sure your netmasks (see netmasks(4)) table, which will be used by your DHCP service, has been updated with this information. You must also collect the IP addresses of the routers on the remote network, or configure clients on the remote network to use router discovery.

After you get all the necessary information, you must decide whether to store data that will be moved across the network in NIS+ or in files. NIS+ is the preferred storage for a multiple service environment, or for an enterprise environment. Files is the preferred storage for a single server, or small environments. After you have collected this information, run dhcpconfig(1M) and configure your remote network.

Choosing a Data Store for DHCP Data

Configuring DHCP name services involves determining which data store resource the DHCP server will use to store its tables and to access host information. The dhcpconfig script sets the DHCP service in the /etc/default/dhcp file. The runtime daemon and administrative utilities will use this file to determine which name service to contact during processing.

How the Datastore Service is Selected

The dhcpconfig command first determines whether NIS+ or files is currently being used by the server system. If NIS+ is currently being used by the system, then nisplus is the default value in the Enter data store prompt. Otherwise, files is the default.

If you choose NIS+ and the server is not running NIS+, a warning message is displayed and you are told how to set up NIS+. The dhcpconfig script continues (although it is likely that errors will occur in the next section when creating DHCP tables).

NIS+ should be used if you have an environment with multiple servers, or an enterprise environment. With NIS+, data can be shared among servers. Files can be used if you have only a single server unless you arrange to share data using NFS.

Create Initial DHCP Tables

The dhcpconfig script creates the following empty DHCP tables in the datastore you selected as shown in Table 16-1.

Table 16-1 Tables Created by the dhcpconfig Script


`dhcptab`	DHCP configuration information table
`dhcp_network`	DHCP client mapping tables, one per network served by the DHCP server

DHCP Tables

DHCP uses two types of databases: network tables and a dhcptab configuration macros table. These databases are NIS+ tables if you are using NIS+, or files if you are not using NIS+.

DHCP Network Tables

A DHCP network table contains information related to IP address allocation. Each network has a separate network table. The tables, called dhcp_network tables in DHCP, derive their names from the IP address of the network they serve. For example, the network table for the network 120.146.5.0 is 120_146_5_0, with underscores replacing periods in the IP address notation.

Each subnet in a DHCP network has a dhcp_network table containing entries for the clients in the subnet. When a client boots and a DHCP server answers its request for parameters, information is recorded as a dhcp_network entry for the client. Among other information, the table includes the client's IP address and a pointer into the dhcptab table.

A network table contains the following specific information:

IP addresses, both assigned and unassigned
Client identifier (for assigned records only)
Lease expiration time
Flag that indicates the type of lease: dynamic, permanent, manual, unusable or BOOTP only
Name of the dhcptab configuration macro for each IP address
IP address of the server that owns the original client IP address

The network table functions as a list of the IP addresses that DHCP servers can assign on a particular network. Each network has its own network table. The key element in the network table is the list of IP addresses. All other elements in the table are significant in relation to the IP address. For example, the client ID identifies the client to which a particular IP address is currently assigned. If the IP address is not currently assigned, then the client ID for that IP address is zero. The expiration time is also zero. When the IP address is assigned, then the client ID and lease expiration time are filled in.

In certain implementations, the client ID becomes the hardware address of the client machine, with a prefix that indicates the network type. For example, a client with an Ethernet address would have 0102608BA614C1 as its client ID, where 01 indicates that the client is an Ethernet network. Other implementations of DHCP may use other identifiers, such as DNS names or property numbers. The important thing is that the client IDs must be unique within the network.

When an IP address is assigned, the lease expiration time for that IP address is set to a specific date and time, or it is marked "No Expiration."

The lease flag and the dhcptab configuration macro name are the same, regardless of whether the IP address is currently assigned to a client. When a client gets a particular IP address, it also gets the type of lease specified by the lease flag and the configuration specified by the property name. The lease flag indicates the conditions under which the IP address can be assigned. The pntadm command manages the dhcp_network table. Example 16-1 shows an example of pntadm output.

Example 16-1 Sample Output: `pntadm` `-P` `129.146.86.0`

Client ID      Flags Client IP       Server IP       Lease      Macro    Comment
                                                     Explanation

010800207CBA2C  04   129.146.86.153  129.146.86.181  Zero       mrcoffee
0108002022519C  00   129.146.86.205  129.146.86.181  7/3/1996   inet11
01080011043B65  08   129.146.86.29   129.146.86.181  Zero       inet11
0100A024A9BCEE  08   129.146.86.198  129.146.86.181  7/22/1996  inet11 	
0100A024A791DE  00   129.146.86.200  129.146.86.181  8/4/1996   inet11 
0100A02463D6EC  00   129.146.86.199  129.146.86.181  8/1/1996   inet11 
0100A024636AB7  00   129.146.86.201  129.146.86.181  8/3/1996   inet11 
010080C72EE4A3  00   129.146.86.206  129.146.86.181  7/5/1996   inet11 
010020AF4A3B31  0    129.146.86.214  129.146.86.181  Zero       hobbs
00              00   129.146.86.202  129.146.86.181  Zero       inet11

The dhcptab ConfigurationTable

The dhcptab table contains information related to client configuration. The table is organized as a series of macro definitions that contain all of the information necessary to configure a network client. A client gets its configuration when it is assigned an IP address from the network table. The macro name associated with the IP address corresponds to a macro name in the dhcptab table. After a client gets an IP address from the network table, it gets its network configuration from the dhcptab table.

During the initial configuration of the DHCP server, the dhcptab table is created with macros for each configured network. Each of these macros contains information specific to the network, including subnet mask, network broadcast address, IP packet time to live, maximum datagram size, default router, static routes, DNS domain, NIS domain, DNS servers, and NIS servers, if these are available when the server is configured.

You can control how client machines access a network by changing the information contained in the macros. For example, changing the name of the macro that a particular client machine uses changes the network configuration of that machine. In a different example, changing a single option within a macro changes the reactions of all the machines that use that macro set. The ability to manage IP addresses is one of the major features of DHCP. The dhtadm command manages the dhcptab server configuration table. Example 16-2 shows an example of dhtadm output.

Example 16-2 Sample Output: `dhtadm` `-P`

Name         Type    Value

mrcoffee     Macro  :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: \
                    :BootSrvA=129.146.86.175:BootFile="/export/root/JavaDesktop/kona": \
                    :NISservs=129.146.86.33:NISdmain=sunsoft.eng.sun.com: \
                    :DNSdmain=Eng.Sun.COM: \
                    :DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19: \ 
                    :Include=Locale: \
                    :Timeserv=129.144.1.3:LeaseTim=3600:T1Time=1800: \
                    :T2Time=3060:	

Locale       Macro  :UTCoffst=25200:SN_TZ="PST8PDT":

inet11       Macro  :Include=Locale:Timeserv=129.146.86.181:LeaseTim=259200: \
                    :DNSdmain=Eng.Sun.COM: \
                    :DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19:

hobbs        Macro  :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: \
                    :BootSrvA=129.146.86.32:BootFile="819256D6.PREP":

129.146.89.0 Macro  :Subnet=255.255.255.0:Router=129.146.89.1:Broadcst=129.146.89.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.89.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

129.146.88.0 Macro  :Subnet=255.255.255.0:Router=129.146.88.1:Broadcst=129.146.88.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.88.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

129.146.87.0 Macro  :Subnet=255.255.255.0:Router=129.146.87.1:Broadcst=129.146.87.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.87.33: 
                    :NetBNms=129.146.171.31:NetBNdT=8:	

129.146.86.0 Macro  :Broadcst=129.146.86.255:Subnet=255.255.255.0:MTU=1500: \
                    :Router=129.146.86.1:NISdmain=sunsoft.eng.sun.com: \
                    :NISservs=129.146.86.33:NetBNms=129.146.171.31:NetBNdT=8: \
                    :BootSrvA=129.146.86.32:

129.146.85.0 Macro  :Subnet=255.255.255.0:Router=129.146.85.1:Broadcst=129.146.85.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.85.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

129.146.84.0 Macro  :Subnet=255.255.255.0:Router=129.146.84.1:Broadcst=129.146.84.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.84.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

129.146.83.0 Macro  :Subnet=255.255.255.0:Router=129.146.83.1:Broadcst=129.146.83.255: \
                    :NISdmain=sunsoft.eng.sun.com: \
                    :NISservs=129.146.83.33:NetBNms=129.146.171.31:NetBNdT=8:

129.146.82.0 Macro  :Subnet=255.255.255.0:Router=129.146.82.1:Broadcst=129.146.82.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.82.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

129.146.81.0 Macro  :Subnet=255.255.255.0:Router=129.146.81.1:Broadcst=129.146.81.255: \
                    :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.81.33: \
                    :NetBNms=129.146.171.31:NetBNdT=8:

SN_TZ        Symbol Vendor=SUNW,13,ASCII,1,0

Configure Each Subnet for DHCP

This section discusses using dhcpconfig to configure subnets, based on your responses to three questions for each subnet:

What range of IP addresses do you want to be searched for unused IP addresses to allocate?
Do you want the DHCP daemon to respond to requests for a specific subnet?
For each monitored subnet, how many clients do you want to be assigned dynamically-allocated IP addresses?

How Each Subnet for DHCP is Configured

The dhcpconfig script creates a table--called the dhcp_network table--for each subnet being configured on the server system. The table name is the same as the IP address, but with decimal points replaced by underscores. For example, the subnet 129.148.5.0 has a dhcp_network table 129_148_5_0 in the name service being used by DHCP. For NIS+, this is a table in the org_dir object. For files, this is a file in the /var/dhcp directory.

Each client system being managed by DHCP has an entry in the dhcp_network table (the table corresponding to the subnet on which the client machine is attached). Entries may be permanent, with the IP address permanently assigned to the machine. Or, entries may be dynamic, where the DHCP server assigns an IP address when the client is first configured and provides a lease, a specified amount of time for which the IP address can be used. It is these dynamic clients that this step attempts to set up. Permanent clients can be set up with pntadm after the DHCP environment is fully configured.

Start the DHCP Service Daemon

This section describes three functions performed by the dhcpconfig script:

Installs the start/stop script for the DHCP daemon processes into the /etc/init.d directory
Sets up links to this script in the /etc/rc{0,3}.d directories
Starts the daemon processes

The start/stop script is named dhcp and the links are S34dhcp (to start the daemons) and K34dhcp (to stop the daemons). This follows standard SVR4 procedure for daemon process execution at boot time.

One daemon process, in.dhcpd, is started. The in.dhcpd daemon is the DHCP server process, which responds to the client DHCP requests and forwards the network configurations, which have been established in the dhcptab table.

Lease Time Policy

DHCP provides a mechanism for dynamically allocating IP addresses. These IP addresses carry a lease period, which you can set to permanent or temporary. Your site policy must include decisions about the number of temporary and permanent IP addresses, and the lease period of temporary IP addresses.

To reap the most benefit from your DHCP service, it's best to allow DHCP to dynamically manage your IP address assignment for you. With DHCP, the client and the server negotiate a loan of an IP address configuration for a certain time period, known as a lease time. You can set a lease time policy based on server, network, client vendor class, or individual client IP address through the use of the LeaseTim and LeaseNeg symbols in certain macro definitions in your dhcptab.

The LeaseNeg and LeaseTim symbols allow you to set policy for your site. LeaseTim is a relative time, such as 24 hours, or 2 hours, or 10 hours. When a client is assigned an IP address (or renegotiates a lease on an IP address it is already assigned), the LeaseTim value is added to the absolute time the client received its DHCP reply. Absolute time is the time now, such as September 27, 1996. The LeaseTim value plus the absolute current time is stored in the client's dhcp_network record as an absolute future time when the client's lease on its IP address expires.

The LeaseTim symbol setting defines the maximum lease time interval you allow to clients. Typically, this value should remain relatively small, so that: clients and servers stay in synch; IP addresses that are not being used are reclaimed in the most timely fashion; and the renumbering of networks happens more smoothly.

However, the value must be large enough so that if your DHCP server becomes unavailable, your clients continue to function until the machine(s) running the DHCP service can be repaired. One to 3 days is an optimal LeaseTim policy. Select values that work well in your environment.

The LeaseNeg symbol determines whether or not a client can renegotiate its lease with the server before the lease expires. If this symbol is present, then the client can renegotiate its lease. LeaseNeg allows clients to operate on the network without lease-related interrupts of existing connections.

Omitting LeaseNeg is useful for environments where you have more machines than you have IP addresses, and thus want to enforce a time limit on the use of any IP address. Enforcing a time limit on machines in a Computer Science class lab is an example of this. Like LeaseTim, LeaseNeg can be used in a variety of different macros in your dhcptab. See dhcptab(4) and dhcp_network(4) for more information.

Machines that export services such as mail or web pages must retain their IP address. However, you'd still like to be able to detect when the IP address used by this node is no longer being used (perhaps when the machine is retired). You can achieve this by marking this node's dhcp_network record as being manually assigned (by you) and by setting the node's flag field to MANUAL. For example, if the hostname is gandalf and the network is 10.50.0.0, type pntadm - gandalf -f MANUAL 10.50.0.0.

You can allocate IP addresses with permanent leases. However, you will not be able to use the DHCP service to automatically reclaim these IP addresses for you. Therefore, keep the number of permanent IP addresses to a minimum, manageable number.

The DHCP service uses this field to determine when dhcp_network record entries have expired and can be reclaimed. You can alter this value through the e option of the pntadm command. Through this command, you can set a client's lease expiration time to the past, although we recommend that you only set it into the future to avoid adversely affecting the client and the client's user(s).

Each time the DHCP service allocates a dynamic IP address or renegotiates a lease on an existing binding, this field in the dhcp_network table is updated.

The lease flag indicates the conditions under which the IP address can be assigned. The flag setting can be a combination of the following:

0 (Dynamic): The IP address lease has an expiration time. When the lease expires it can be renewed, if that is indicated by the site policy. If the current client does not renew the lease, then the IP address can be assigned to another client. When the flag is set to 0, the client can request that the lease time be changed.
1 (Permanent): The IP address lease is assigned permanently, and the client cannot change the lease time. However, the client using the IP address can release it. When it is released, it can be assigned to another client.
2 (Manual): The IP address is assigned to a specific client machine. It cannot be released by the client. As long as the flag is set to 2, the IP address can be reassigned only if an administrator changes it manually.
4 (Unusable): The IP address is unusable. You can set the flag to 4 to prevent an IP address from being assigned. The DHCP server marks an IP address as unusable if it attempts to locate the IP address and finds that it is already in use. Before it assigns an IP address, the DHCP server normally pings it to see if it is already in use for some reason. This setting is configurable in dhcpconfig.

The flag can also have a combination of settings. For example, if the flag is set to 3, it is a combination of 1 and 2; that is, it is both permanent and manual. The IP address has a permanent lease, and was assigned by the administrator.

Setting Up a BOOTP Relay Agent

First, determine if your router or routers has a built-in relay agent. If the router does, read the documentation to understand how to use the relay agent. If your router does not have a built-in relay agent, choose a Solaris 2.6 machine on the client's network to act as the relay agent. Install SUNWdhcsr and SUNWdhcsu on the machine. Then run dhcpconfig and select Configure BOOTP relay agent.

Enter the IP addresses or hostnames of the BOOTP/DHCP servers to which you want to send BOOTP/DHCP requests.

Standard DHCP Options

The Solaris 2 DHCP server implements all of the standard DHCP options. These options contain network information such as:

Server names
Router address
DNS Domain Name
TCP Time to Live
Connection options
Server options
IP layer options
Time options

Vendor Options

Vendor options are DHCP options that are defined by the DHCP client software vendor. When a client broadcasts a request for a configuration, the client includes its vendor client class. If this client class matches any client classes in the dhcptab database, then the options specified for that class are sent to the client, along with other configuration options. The Solaris 2 DHCP server can be configured to support any DHCP client vendor's options.

Adding Vendor and Site Options

To create additional vendor or site options, you must define:

Vendor class, which is the name used to distinguish clients by vendor. The class name is an ASCII character string. It is not specified when you are defining a site option.
Value type, which specifies the type of data contained in this option. The supported data types are:
- ASCII text
- Octet, an ASCII representation of binary data
- IP, the dotted decimal form of an Internet address
- Number, an 8-bit, 16-bit, 32-bit, or 64-bit number
Option Code, which is the DHCP option number you want to assign to the new options. Vendor codes can be between 1 and 254; site codes can be between 128 and 254.
Granularity, which specifies how many objects of this value type make up a single instance of this option. For example, the static route symbol is a list of routes. Each route consists of two IP addresses, so the value type is defined as IP and the granularity is defined as 2.
Length, which specifies the minimal granularity permissible in this option. For example, a subnet mask can be only one IP address, so the length for the subnet mask option is 1. A value of zero means that a variable number of items, up to 16, is permitted.

Because site options are specific to your site, you can create any meaningful option. In the case of vendor options, however, you can add only options that are meaningful to a specific client vendor. Some options are predefined, but others must be created. In that case, you may need to create a list of vendor options on the server that are appropriate to the specific vendor. The list typicall is provided by the client vendor.

Creating Macro Definitions

When you create a macro for the dhcptab table, you must specify all of the relevant standard, vendor, and site options. You do not have to specify all the options available. How many you specify depends on how your network is configured.

IP Address Leases

IP address leases are assigned as temporary by default. Temporary leases are useful if users and their machines change subnets frequently, or if systems come in and out of use fairly often.

Each site can specify whether the temporary leases on the site are renewable. You can set this site policy in the properties table with the LeaseNeg symbol. If you omit this symbol, the client cannot renegotiate its lease when it expires. If a client does not renew its IP address when it expires, it can be reused.

Customization Examples

To change an NIS server value for the network 126.147.100.0:

Edit the macro 129.147.100.0 with:

dhtadm -M -m 129.147.100.0 -e `NISserv = 129.147.100.1 129.147.100.2'

Type:
/etc/init.d/dhcp stop

Type:

/etc/init.d/dhcp start

Or, instead of steps 2 and 3, use the -t option to in.dhcpd.

To add addresses from 10-15 to 129.147.100.0

for addr in 10 11 12 13 14 15  
do  
	pntadm -A 129.147.100.$addr -m server -h hundred-$addr 129.147.100.0
done

To add a symbol definition for a timezone; SN_TZ

Type:

dhtadm -A -s SN_TZ -d  'Vendor="SUNW.PCW.LAN SUNW.Solaris", 13, ASCII, 1, 0'

Type:

dhtadm -M -m Locale -e `:SN_TZ = "EST5EDT4":'

Type:
/etc/init.d/dhcp stop

Type:
/etc/init.d/dhcp start
or -t option

To delete the Timeserv value from the jurassic macro:

Type:
dhtadm -D -m jurassic -e `Timeserv=`

Type:
/etc/init.d/dhcp stop

Type:
/etc/init.d/dhcp start
or -t option

Always return hostnames to the client of the server jurassic.

Type:

dhtadm -M -m jurassic -e `Hostname= _NULL_VALUE_'

Type:
/etc/initd/dhcp stop

Type:
/etc/init.d/dhcp start
or -t option

If it is important to maintain the hostname-to-IP address association for a host named canoepoint to an IP address association, mark the canoepoint entry on the peds network as MANUAL.

Type:
pntadm -M canoepoint -f MANUAL peds
or

Type:
pntadm -M canoepoint -f 02 peds

In order to mark 129.147.100.87 as BOOTP and permanent:

Type:

pntadm -M 129.147.100.87  -f `BOOTP + PERMANENT' 129.147.100.0

Type:

pntadm -M 129.147.100.87 -f 09 129.147.100.0

Maintenance

This shell script first checks any IP addresses marked as unusable to verify that they are not in use. If they are not, the script then reclaims the IP addresses.

#!/bin/ksh
# This shell script reclaims addresses which were marked as unusable, after
# first verifying that they're no longer in use.

if [ ${#} -eq 0 ]
then
     echo "reclaim <network> ..." >&2
     exit 1
fi

while [ ${#} -ne 0 ]
do
     pntadm -P ${1} | awk ' $2 == 04 { printf("%s %s\n", $1, $3); }' |
     while read cid addr
     do
        if [ ${?} -ne 0 ]
        then
             pntadm -M ${addr} -i 00 -f DYNAMIC -e 0 ${1}
             if [ ${?} -eq 0 ]
             then
                 echo "${addr} has been reclaimed from client ${cid}."
             fi
             else
                 echo "${addr} is in use!" >&2
             fi
     done
     shift
done
exit 0

Enabling the Solaris DHCP Client

By default, the Solaris DHCP client is disabled. To enable it, you must create a DHCP enable file for each network interface you want to configure with DHCP. The format of the DHCP enable file is: /etc/dhcp.interface_name, where interface_name is the name of the network interface you want configured by DHCP.

For example, if you would like to configure network interface le1 using DHCP, you would create the empty file /etc/dhcp.le1. If you have multiple network interfaces that you would like to configure using DHCP, you must create a DHCP enable file for each interface.

Increasing Boot Process Suspension Time

Using DHCP to configure an interface may increase the boot time. In particular, if no DHCP server is present to answer the client's requests, a delay of approximately 30 seconds occurs for each interface. If you want your Solaris DHCP client to suspend the booting process until the network interface is configured (regardless of how long this takes), edit the network interface's DHCP enable file (/etc/dhcp.interface_name) and add the phrase wait forever.

If you want your client to suspend its booting process for a shorter period of time, you can specify the number of seconds to wait instead of using the keyword forever. For example, if you want to allow DHCP one hour to configure the network interface before the booting process continues, specify wait 3600.

Note -

Even if the suspend time is exhausted, the Solaris DHCP client will continue asynchronously to configure the network interface until it is successful. To avoid this, you can specify the drop option to the ifconfig(1M) command. For example: ifconfig le0 dhcp drop. This will remove the specified interface (in this case, le0) from the control of the DHCP agent, which should cause the asynchronous address allocation attempts to terminate.

Designating a Network Interface as Primary

Many DHCP configuration parameters are not specific to a network interface. Instead, the parameters specify more general information. Examples of this type of general parameter are: NIS server, NIS domain, DNS servers, and DNS domain. If your Solaris machine has only a single network interface, there does not need to be a distinction between the general and interface-specific parameters.

However, if your machine has multiple network interfaces (it is multihomed), and DHCP is to configure more than one interface, then it is possible to receive multiple sets of general configuration parameters that may conflict. For example, which DNS parameters should be used? Those received when using DHCP to configure interface le0 or those received for le1?

The Solaris DHCP client solves this problem by allowing you to specify one network interface as the primary network interface. Interface-specific parameters (such as subnet mask) will be retrieved from the DHCP parameters for that specific interface. General parameters are retrieved only from the DHCP information received on the primary interface.

To designate a network interface as the primary interface, add the keyword primary to the DHCP enable file for that interface. For example, suppose you want to use qe2 as the primary interface. Edit /etc/dhcp.qe2 and add the word primary.

If the keyword primary is not added (no interface has been designated as primary), the Solaris machine receives parameters from the first interface that is configured successfully.

Network Topologies That Limit Effective Use of DHCP/BOOTP

DHCP and BOOTP clients initially have no information about the local IP network, and therefore use the 0.0.0.0 (the default network address) for their IP address. The clients send their DHCP or BOOTP requests to the 255.255.255.255 IP address (broadcast address) which will be received by all IP devices attached to the local IP network.

DHCP and BOOTP servers determine the client's IP network attachment based on following factors:

Which network hardware interface the DHCP or BOOTP request was received on?
Was the DHCP or BOOTP request received from a BOOTP relay agent?

BOOTP relay agents insert the IP address of their network hardware interface that is attached to the same IP network as the DHCP or BOOTP client. The absence of this IP address signals to the server that the client is on a directly-attached IP network. The presence of this IP address indicates that the client is attached to an IP network remote from the server and that the server is to send responses back to the client using the BOOTP relay agent's IP address.
Is the IP network the client is attached to subnetted?

The servers, using the IP address as a key, consults the contents of the netmasks table (which contains subnet mask information) using either:
- The IP address of the server's network hardware interface if the client is on a directly-attached IP network (indicated by an IP address of 0.0.0.0 in the packet's relay address field)
- The IP address specified if a BOOTP relay agent specified its IP address in the client's request
(See netmasks(4) for information on netmasks.)

This procedure for determining the client's IP network attachment is only effective if there is only one IP network present on the network hardware media (for example, Ethernet). DHCP does not work well in IP network environments where, either through the use of multiple network hardware interfaces or multiple logical interfaces, there is more than one IP network sharing the same network hardware media. In this case, a DHCP client's request appears on all network hardware interfaces, making the client "appear" to be attached to all of the IP networks simultaneously. Since DHCP servers dynamically allocate IP addresses to requesting clients, the server is unable to determine which IP address to allocate to the client. DHCP clients, attempting to validate IP addresses they presently hold, will be seen to originate on all the logical IP networks, not just the network the client has been assigned to.

Such network topologies should be avoided, either though the use of Variable Length Subnet Masks (VLSM) to preserve the one-to-one mapping of IP network to network hardware media through more efficient subnetting, or by configuring the DHCP or BOOTP service to serve just one of the logical IP networks. See netmasks(4) for additional information.

Chapter 17 Troubleshooting DHCP

This chapter describes how to troubleshoot problems you may encounter while using DHCP. It includes solutions to problems you may have when installing and configuring the first DHCP server. To further help you troubleshoot server problems, this chapter also includes background information about the DHCP server configuration script (dhcpconfig) - the purpose of various script components and how the script executes installation procedures. It also describes problems you may encounter as you add your first and subsequent DHCP clients to the network.

Strategies and Tips

The following troubleshooting techniques are helpful in solving problems when you cannot isolate the cause:

Use the snoop command to monitor network traffic.
Run the DHCP client in debug mode.
Run the DHCP server in debug mode.
Reboot the DHCP client.
Stop the DHCP server. Then start it again.

This chapter describes these techniques in more detail. It also tells you where to get more information when you cannot solve a problem using this guide.

Using `snoop` to Monitor Network Traffic

You can use the snoop command to monitor network traffic.

To Use `snoop` to Monitor Network Traffic

Use the snoop command to trace network traffic. For example:
snoop -o /tmp/output udp port 67 or udp port 68

Boot the client and watch the DHCP message exchange between the client and server(s).

Type:
snoop -i /tmp/output -x 0 -v

You can limit the scope of snoop by specifying the client's hardware address. A version of snoop that understands the DHCP/BOOTP protocols is available in Solaris version 2.5 and later.

Running the DHCP Client in Debug Mode

Running the DHCP client in debug mode reveals much of the ongoing dialogue between the client and the server. Refer to the documentation for the product on which you are running the client.

To Run a Solaris 2 Client in Debug Mode

Debugging the DHCP client is only possible after it has booted. If DHCP problems are experienced, you must boot with DHCP disabled. The steps here can be performed only once after the host has booted, preferably in single-user mode.

The DHCP agent can be configured to log details of the packets exchanged with the server. To do this, the agent must be started with debug mode turned on:
/sbin/dhcpagent -n -d3 &
The -d3 flag turns on debug at leve1 3, and the -n flag says "don't configure the interface even if DHCP is successful".

Note -
Level 3 and levels below that return appropriate information for the user. Levels above level 3 are appropriate only for developers or those with even more expertise, since they return raw packets of information.

Only one instance of dhcpagent can run at a time, so before the agent can be started in this manner, any previously invoked agent must be stopped. To do this, find the agent's process ID and send it the terminate signal:
kill -TERM process_id_of_dhcpagent

After an agent has been started in debug mode, try to configure an interface manually by typing:
ifconfig interface_name auto_dhcp
The packets that are sent, and any that are received, will be displayed.

Note -
During the time that DHCP tries to configure an interface, the interface is unable to send or receive packets. Other network services, such as NIS or NFS, may be adversely affected while the interface is down.

To Run the DHCP Server in Debug Mode

Stop and restart the DHCP server in debug mode.

For example:

Stop the server using the shutdown script:
/etc/init.d/dhcp stop

Restart the server in debug/verbose mode, using the -d and -v flags in addition to any flags specified in the /etc/init.d/dhcp startup script. For example, if the i option is present, type the command in the following format:
/usr/lib/inet/in.dhcpd -i interface_names -d -v

Restarting the DHCP Client

Once you have run the DHCP client in debug mode, you can try rebooting. Rebooting resets the network hardware and software.

To Restart the DHCP Client

Reboot the client.

To Restart the DHCP Server

Type:
/etc/init.d/dhcp stop
Wait about 10 seconds.

Type:
/etc/init.d/dhcp start

To Restart the DHCP Server After Debugging is Completed

Restart the DHCP server daemons.

Type:
/etc/init.d/dhcp stop
Wait about 10 seconds.

Type:
/etc/init.d/dhcp start

Common Problems

This section describes some of the more common problems you may encounter with DHCP, and what to do about them.

Problem

The DHCP client is sending out DHCPDISCOVER or DHCPREQUEST messages, but the DHCP server is not responding.

Verification: Check the server machine's console. It may not have any IP addresses left to allocate.

Solution: Add more IP addresses.

Verification: Check the server machine's console. If the server is stating that the client is unrecognized, then the DHCP server's databases may have been flushed, with the result that the server fails to recognize the client.

Solution: Remove any DHCP cache file on the client.

Interrupt the boot by typing Control -C.

Remove the cache by typing:
cd /etc/dhcp; rm interface_name.dhc

Restart the initialization process by typing
ifconfig interface_name dhcp release

Verification: Check the server machine's console. Perhaps support for the client's network has not been added to the DHCP databases.

Solution: Add support for the client's network, using dhcpconfig.

Verification: The client is on a network separate from that of the DHCP server, and a BOOTP relay agent has not been installed or configured.

Solution: Install and configure a BOOTP relay agent. In addition, you may need to add an entry to the netmasks(4) database for the remote network.

Problem

The client logs a message that the address is already in use.

Verification: Check whether the address is in use elsewhere. If the client continues to log the same message, it is likely that the server is not checking the address, or is ignoring the client's message which declines the address. Check to be sure you are not using the in.dhcpd command with the n option.

Solution: Find out whether the server gave out the bad address. Either the server is malfunctioning, or another user has illicitly used the same address.

Problem

The following error message is displayed:

DHCP renewal on interface_name failed

Verification: The DHCP client was unable to renew a lease on the specified interface.

Solution: Make sure that the DHCP server is still running correctly.

Problem

The following message is displayed:

Address of interface name has changed

Verification: The address or status of the interface is not what the DHCP agent expects to see. The address was probably altered manually.

Solution: There is no solution. The agent will stop trying to configure the interface.

Where to Get More Help

If after using these instructions you need further assistance, please call your local Solaris sales or service representative. To ensure that you receive the best possible service, have the following information ready before calling for help.

Exact error message you received (if any)
Version of the operating system running on the client
Machine type
Type of network (Ethernet, Token Ring, FDDI or PPP)

Troubleshooting the DHCP Server

This section discusses problems you may have with your DHCP server.

When Using Files

Follow the instructions below if you have problems while using files as a name service.

Problem

You cannot access the /var/dhcp directory; it either does not exist or you do not have UNIX file permissions to read it.

Verification: Use the following command:

ls -d /var/dhcp

Solution: The DHCP server hasn't yet been configured. Run dhcpconfig.

When Using NIS+

Follow the instructions below if you have problems while using NIS+ as a name service.

Problem

The root object does not exist in the NIS+ domain.

Verification: Enter the command:

niscat -o org_dir

Solution: Refer to Solaris NIS+ setup documentation.

Problem

The root account does not have access rights to create a table under the org_dir object.

Verification: Enter the command:

niscat -o org_dir

Solution: Use the nischmod command to change the permissions on the table.org_dir.domainname.

Problem

The root account does not have access rights to create a table under the org_dir object. Usually, this means the root account's principal name is not a member of the owning group for the org_dir object, or no owning group exists.

Verification: Enter this command to find the owning group name: niscat -o org_dir

Solution:

Enter nisgrpadm -l group to see the group members.

If the current system's principal name is not in the group, enter: nisgrpadm -a group principalname to add it. Typically, the group is admin. If it is not, edit the dhcpconfig script and change the group to match the group name in use.

Enter /usr/lib/nis/nisctl -fg to flush the cache for immediate update.

Problem

The domain name is unset.

Verification: Enter the command:

domainname

If the command lists an empty string, no domain name has been set for the domain.

Solution: Use the domainname command to set the proper domain name. Place the domain name value in the /etc/default domain.

Problem

The NIS_COLD_START file does not exist.

Verification: Enter the following command on the server system:

strings /var/nis/NIS_COLD_START

Solution: Create a NIS+ client. Refer to the Solaris NIS+ QuickStart documentation.

Problem

You choose NIS+ and the site is not running NIS+.

Verification: Log on to the server. Type in the command:

 ps -ef | grep nis

If NIS+ is running you will see output similar to: /usr/sbin/rpc.nisd -YB.

Solution: Create a NIS+ server:

On the client, set up the NIS+ root master server for the domain. For example:
/usr/lib/nis/nisserve -r

Populate the NIS+ tables from the local /etc files. For example:
nispopulate -F /etc

On the server, verify that NIS+ is running. For example:

/usr/lib/nis/nisstat
nisls org_dir  
niscat hosts.org_dir

Cannot Use NIS+ as Name Service

One or more of the following error messages are displayed:

!!! warning !!! trailing dot ignored - use dns domain name syntax

Error 20 from NIS+; unable to use NIS+ as name service.

These messages mean either that there is no such name in the NIS+ domain, or the NIS+ domain does not exist. Use the information below to find and solve errors in the configuration of NIS+.

Problem

The domain name for the server system ends with a period.

Verification: Enter the nisdefaults command to determine whether there are two trailing periods after the domain name.

Solution:

Edit the /etc/defaultdomain file by removing the trailing period (.) from the domain name.

Reboot your system, and rerun the dhcpconfig script.

Problem

A host name includes the domain name. For example, setting a host to myhost.Faxco.COM instead of myhost.

Verification: Enter the nisdefaults command to show a host name with the domain name included twice.

Solution:

If your host name is set incorrectly, enter the sys-unconfig command to remove the configuration settings and halt the system.

Reboot the system and supply the correct settings for host name and domain name.

Problem

The root account does not have create access to the org_dir object in the NIS+ domain.

Verification: Enter the command:

niscat -o org_dir

Solution: Use the nischmod command to change the permissions on the table.org_dir.domainname.

I/O Error Accessing File Name Service

The following error message is displayed:

File system I/O error number accessing file datastore.

If you receive this error message, look through the list of error messages below, which are returned by the operating system when it tries to open, read, or write a file in /var/dhcp.

Problem

The error number is 2 (ENOENT).

Verification: The file or directory does not exist.

Solution: Enter the dhcpconfig command to create it.

Problem

The error number is 13 (EACCES).

Verification: A UNIX permission error occurred accessing the file or directory.

Solution: Use the su command and change the UNIX permissions.

User Has no DES Credentials

Problem

The following error message is displayed:

The user user does not have DES credentials in the NIS+ name service.

Verification: The current system's root account does not have valid Data Encryption Standard (DES) credentials in the NIS+ cred table.

Solution: Use the nisaddcred command to add the credentials for the root account. You must enter the UNIX netname and NIS+ principal name on the command line.

The following example shows how to add DES credentials for the system mercury in the domain Faxco.COM.

nisaddcred -p unix.mercury@Faxco.COM \
-P mercury.Faxco.COM. DES Faxco.COM

The command prompts for the root password (which is required to generate an encrypted secret key).

No Permission to Create Table in Data Store

The following error message is displayed:

You do not have permission to create the tablename table in the servicename data store.

If you have a problem creating tables in the data store, check the information below.

Problem

The root account does not have access rights to create a table under the org_dir object.

Verification: Usually, this means the root account's principal name is not a member of the owning group for the org_dir object, or no owning group exists.

Solution:

Enter niscat -o org_dir to see the name of the owning group.

Enter nisgrpadm -l admin to see the group members.

If the current system's principal name is not in the group, enter nisgrpadm -a group principalname to add it.

Enter /usr/lib/nis/nisctl -f g to flush the cache for immediate update.

Unable to Determine Name Servers

Solutions to problems in finding a name server during configuration of the DHCP server are listed below.

Problem

The dhcpconfig script could not match server names with IP addresses.

Verification: Find the IP address of the server by using the command getent hosts name.

Solution: Create the entries in the hosts database.

Problem

The dhcpconfig script is using the wrong name service for the server.

Verification: Look at the hosts entry in the /etc/nsswitch.conf file to see which name service is used to look up IP addresses (xfn, files, nis, nisplus, dns).

Solution: Change the hosts directive in the /etc/nsswitch.conf file to the correct name service. Stop and restart nscd.

Problem

The dhcpconfig script did not check the name service.

Verification: The name service preceding the [NOTFOUND=RETURN] directive in the /etc/nsswitch.conf file is authoritative. If the specified name service does not find an entry, any name services listed after this directive are not checked.

Solution: Remove the [NOTFOUND=RETURN] directive from the /etc/nsswitch.conf file and run the dhcpconfig script again. Stop and restart nscd.

Errors Trying to Set Up DHCP Table

One of the following error messages is displayed:

The user username does not have permission to update the dhcptab table in the servicename resource.

Error 10 from the Table subsystem accessing dhcptab table, message: NIS+ error while executing nis_modify_entry for [key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean.: Permission denied Error trying to set up DHCP table, exiting.

Error 10 from the Table subsystem accessing dhcptab table, message: NIS+ error while executing nis_modify_entry for [key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean.: Object with same name exists Error trying to set up DHCP table, exiting.

If you receive one of these error messages, check the information below for solutions to problems trying to set up DHCP tables during the configuration of the DHCP server.

Problem

You do not have access rights to add entries into DHCP tables from NIS+ or the UNIX file system.

Verification: Check permissions and set appropriate access rights for the DHCP table.

Solution: Make sure the administrator is a member of the appropriate administrative group and has write access to the NIS+ master server.

No Permission to Access `dhcp_network` Table

The following error message is displayed:

You do not have permission to create {update} the tablename table in the servicename data store.

If you receive this message, check the information below regarding a problem. Listed below are solutions to problems accessing the dhcp_network table during the configuration of the DHCP server.

Problem

You do not have access rights to add entries into the dhcp_network table from NIS+ or the UNIX file system.

Verification: Check permissions and set appropriate access rights for the dhcp_network table.

Solution: Make sure the administrator is a member of the appropriate administrative group and has write access to the NIS+ master server.

Troubleshooting a DHCP Client

When troubleshooting a DHCP client, you must understand certain issues about configuring the client and client-server communication. DHCP may fail to configure the client properly, either because DHCP could not communicate with a server, or because, although configuration responses were received, they were incorrect. Problems can also occur later in the life of a DHCP lease if the client cannot renew its IP addresses.

Client Cannot Communicate With the Server

When a client and a server cannot communicate with each other, the consequences depend on whether or not the client has a configuration cached from an earlier DHCP transaction. If it has, and if the lease is still valid, the client will use the cached data to configure the interface.

However, because the client has received no outside confirmation that this configuration is valid, there is no guarantee that the IP address, router address, and other information are valid. If the interface is connected to a network other than the one on which the configuration was received, one of two things can happen. Either errors may appear when other network services are started, or it may be impossible to communicate with other hosts on the network.

On the other hand, if no cache with an unexpired lease exists, the interface is not configured.

DHCP Configurations Received Are Invalid

Configurations can be invalid for two reasons:

The client determines by ARP that the IP address offered to it is in use elsewhere. In this case, the client will send a DHCPDECLINE message to the server. If the server offers more than two bad addresses, dhcpagent fails.
The client gets offers, but when it tries to confirm them, the server sends a DHCPNAK message instead of a confirmation. If the client receives DHCPNAK messages more than twice, dhcpagent fails. This indicates a malfunctioning server.

Isolate the Problem to the Client or Server

Perform the following actions to isolate the problem to either the client or the server machine.

Problem

The DHCP server machine is not working.

Verification: Log in to another machine on the same subnet as the client, and use the ping command to try to reach the server.

Solution: Diagnose the problem on the server machine.

Problem

The DHCP server is not running.

Verification: Log in to the server and enter the command:

ps -ef | grep dhcp

Solution:

Stop and restart the DHCP server.

Enter the command:
/etc/init.d/dhcp stop

Wait about 10 seconds. Then enter the command:
/etc/init.d/dhcp start

Problem

The boot process hangs during DHCP.

Verification: The interface is marked primary, but no valid DHCP transaction has occurred.

Solution: Interrupt DHCP by typing control-C. The boot continues.

Note -

Although booting continues, the host may be incorrectly configured for the networks to which it is attached.

Client Cannot Reach DHCP Server

Problem

After configuring the DHCP client software and rebooting the client, you are unable to reach a server on the network from the client. All DHCP network commands fail and you see messages that the client is trying to reach the DHCP server and failing.

Typical error messages include:

DHCP or BOOTP server not responding A request to access nonexistent dhcp_network database: databasename in datastore: datastore. No more IP addresses for network_address network.

Verification: To pinpoint exactly what the problem is, perform the following actions.

Run the client in debug mode.

Attempt to configure the interface manually to verify that the hardware is functioning.

Run the DHCP server in debug mode.

Use snoop to trace messages sent between the DHCP server and client.

Find out if the problem is on the client or server machines.

Look at the error message and choose a solution from the information below.

Run Client in Debug Mode

Run the client in debug mode. Refer to the documentation for the product you are running.

Solaris 2 Client:

Invoke:
/sbin/dhcpagent -d3

DOS Client

On a PC-NFS DOS client:

Edit the AUTOEXEC.BAT file by replacing SNCLIENT with SNCLIENT /D.

Reboot the client.

Configure the Interface Manually

After dhcpagent has been started in debug mode, you can try to configure an interface manually by typing:

ifconfig interface_name auto_dhcp

Packets that are sent, and any that are received, will be displayed.

Run the Server in Debug Mode

Kill and restart the DHCP server in debug mode. For example:
/etc/init.d/dhcp stop /usr/lib/inet/in.dhcpd -d -v
Or, if the i option is present, enter the command in the following format:
/usr/lib/inet/in.dhcpd -i interface_names -d -v

Use `snoop` to Monitor Network Traffic

Use the snoop command to trace network traffic. For example:

snoop -o /tmp/output udp port 67 or udp port 68

snoop -o /tmp/output udp port bootps or udp port bootpc

plus the per-interface argument, if there is one.

Boot the client and watch the network messages on the server.

Type:
snoop -i /tmp/output -x 0 -v
to view the packet traces.

Look up Error Messages

Look at the output from running the in.dhcpd command in debug mode and use the error message or condition you see to find a solution from the information below.

Problem

You see one of the following error messages:

Datagram received on network device: le0

ICMP ECHO reply to OFFER candidate: ip_address disabling

Verification: Before the DHCP server offers an IP address to a client, it verifies that the IP address is not in use by pinging the IP address. If a client replies, the IP address is in use.

Solution: Make sure the IP addresses you configured are not already in use.

Problem

You see the following error message:

No more IP addresses for network_address network

Verification: There are no available IP addresses in the client's dhcp_network table.

Solution: Use the dhcpconfig command to allocate more IP addresses. If the DHCP daemon is monitoring multiple subnets, be sure the additional IP addresses are for the subnet where the client is located.

Problem

There is a bad client id: id_name in the dhcp_network database.

Verification: The client ID (MAC address) in the dhcp_network table is incorrect.

Solution: If you are using Ethernet, the client ID is 01 followed by the Ethernet address. Make sure that all letters in this address are capitalized. A 00 means the address has not been assigned.

Problem

You see the following error message:

Request to access nonexistent dhcp_network database: database_name in datastore: nisplus_datastore.

Verification: The dhcpconfig script did not create a dhcp_network table for a subnet during the configuration of the DHCP server. This can happen if you set up an isolated LAN, such as a server and two clients, as a test network.

Solution: Use the dhcpconfig command to initialize the dhcp_network table and new IP addresses.

Problem

You receive the error message:

Client client_id is trying to verify unrecorded address ip_address, ignored.

Verification: There are two possible reasons for getting this message:

You can receive this message if your dhcp_network tables have been deleted. If you are using only the Solaris 2 DHCP server, then this is typically the reason.
You can receive it if you are not using NIS+ for datastore, so information is not shared. Make sure that the server is sharing data.

If you have a group of heterogenous servers, then ignore this message.

Solution: Remove old cache files on the client by typing:

ifconfig interface_name dhcp release

Problem

DHCP is started, but some required network services will not start.

Verification: The DHCP server is not supplying the configurations required.

Solution: Find out why the server does not send the parameters that are required. Configure the server to do so.

Problem

DHCP is started, but certain network services, such as NIS and NIS+, report errors or hang. The host cannot communicate with other hosts on the network.

Verification: The dhcpagent command was unable to communicate with DHCP (presumably because DHCP was unavailable) and has used cached data.

Solution: Remove the cache. Type:

ifconfig interface_name dhcp release

Since removing the cache does not solve the problem of getting the proper configuration, the host may have to be configured by hand. At boot time, DHCP should be disabled by removing the trigger file by typing:

rm /etc/dhcp.interface_name

Problem

The client boots and works correctly, but the following message appears:

DHCP renewal on interface_name failed

Verification: DHCP is working, but dhcpagent cannot contact the server to extend the lease.

Solution: Find out why the server is not responding now. This could be because the router value configured in the dhcptab is incorrect or out of date for the client network.

Problem

Messages about failed DHCP renewals are received. Then the following message appears on the console:

DHCP lease expired on interface_name: interface is now down

Network services may hang at this point.

Verification: The lease has expired. The client has not been able to extend the lease after several attempts.

Solution: Find out why the server is not responding. Reboot the client.

Some Clients Do Not Boot From DHCP Server in BOOTP Compatability Mode

Problem

The DHCP daemon is running in BOOTP compatibility mode (-b option).

Verification: BOOTP does not use a lease time. The DHCP server looks for free addresses with the BOOTP flag set to allocate the BOOTP clients.

Solution: Allocate BOOTP addresses. Use dhcpconfig to change the daemon options.

Diagnose NIS+ Configuration Problems

Use the information below to fix errors in the configuration of the NIS+ name service that prevent the client from accessing a server during boot.

Problem

No name service is configured for the client in the dhcptab table.

Verification: Log in to the server and type the command:

dhtadm -P | grep ip_address

Check for entries such as NISdmain, DNSdmain, and NISservs. Make sure the addresses entered for them are correct. For example:

# dhtadm -P | grep 129.148.3.129.148.3.m:Subnet=255.255.255.0:Router=129.148.3.11: 
Broadcast=129.148.3.255:NISdmain="island.ocean":NISservs=129.148.3.3:

Note -

The line above actually appears on one line, instead of being broken into two.

Solution: Use dhtadm to change any incorrect addresses.

Problem

You are using NIS+ and the server is not running in NIS+ compatibility mode. NIS+ tables do not have read rights for the Nobody category, so NIS clients cannot access the information stored there.

Verification: Run the command:

nisls -l org_dir

to show permissions of .r---rmcdrmcdr---

Check whether the Y option is set for the rpc.nisd daemon. For example:

ps -deaf | grep nis

Solution:

Enter the command:

/usr/lib/nis/nisserver -r -Y -d domainname

Problem

An incorrect default router prevents the client from reaching a server on another network.

Verification: Make sure the router symbol definition in the dhcptab table is actually a router.

Solution: Use dhtadm to correct the route symbol in the table.

Problem

You are running NIS+ but DNS forwarding is not turned on for NIS clients.

Verification: Use the command:

ps -ef | grep rpc.nisd

A -B option means that NIS is running with DNS forwarding turned on. For example:

/usr/sbin/rpc.nisd -B

Solution: Start the NIS+ server in NIS compatibility mode with DNS forwarding enabled. For example:

/usr/sbin/rpc.nisd -YB

Diagnose Name Service Configuration Problems

Use the information below to fix errors in the configuration of the NIS name services that prevent the client from accessing a server during boot.

Problem

An incorrect default router prevents the client from reaching a server on another network.

Verification: Make sure the router symbol definition in the dhcptab table is actually a router. If there are problems with the default router, make corrections with server-based tools.

Solution: Use dhtadm to correct the route symbol in the table.

Problem

No name service is configured for the client in the dhcptab table. For clients, the name service must be DNS, NIS, or NIS+, and appropriate parameters must be provided to each client.

Verification: Check the network-specific macro relating to the client's configuration.

Look for an entry that matches your client's network.

Solution: Use dhtadm to correct the client's macro for the name service:

If this is the first client on the network:

Use dhtadm to correct the entries.

Then type:
/etc/init.d/dhcp stop, /etc/rc3.d/S34dhcp start
on the server and reboot the client.

Note -
The server does not dictate the name service choice to the client. The server only provides the relevant information. The client chooses its name service.

Macro Change Not Propagated to Client

You have changed one or more macros for a client with dhtadm, but the changes are not evident on your machine. For example, you changed the client's router, but the client is still using the old router.

Use the information below to solve the problem of changed client macros not showing up on the DHCP server.

Problem

The DHCP server was not reinitialized to read your changes to the dhcptab table. This must be done every time you change a macro definition.

Solution: Use the rescan option-set with dhcpconfig, or:

Reinitialize the DHCP server:

Enter:
/etc/init.d/dhcp stop

Restart the DHCP daemon by entering:
/etc/init.d/dhcp start

Part IV Dynamic Host Configuration Protocol

Chapter 14 Understanding DHCP

What is DHCP?

Figure 14-1 DHCP Architectural Diagram

The DHCP Client

Delivering Client Information

Supplying Additional Information

DHCP Server

Server Databases

BOOTP Relay Agents

Leases

Chapter 15 Moving to DHCP

Why Move to DHCP?

Advantages of DHCP

Migration

Subnets

Routers

Chapter 16 Administration of DHCP

Collecting Information Before Setting Up a DHCP Service

Choosing a Data Store for DHCP Data

How the Datastore Service is Selected

Create Initial DHCP Tables

DHCP Tables

DHCP Network Tables

Example 16-1 Sample Output: pntadm -P 129.146.86.0

The dhcptab ConfigurationTable

Example 16-2 Sample Output: dhtadm -P

Configure Each Subnet for DHCP

How Each Subnet for DHCP is Configured

Start the DHCP Service Daemon

Lease Time Policy

Setting Up a BOOTP Relay Agent

Standard DHCP Options

Vendor Options

Adding Vendor and Site Options

Creating Macro Definitions

IP Address Leases

Customization Examples

Maintenance

Enabling the Solaris DHCP Client

Increasing Boot Process Suspension Time

Designating a Network Interface as Primary

Network Topologies That Limit Effective Use of DHCP/BOOTP

Chapter 17 Troubleshooting DHCP

Strategies and Tips

Using snoop to Monitor Network Traffic

To Use snoop to Monitor Network Traffic

Running the DHCP Client in Debug Mode

To Run a Solaris 2 Client in Debug Mode

To Run the DHCP Server in Debug Mode

Restarting the DHCP Client

To Restart the DHCP Client

To Restart the DHCP Server

To Restart the DHCP Server After Debugging is Completed

Common Problems

Where to Get More Help

Troubleshooting the DHCP Server

When Using Files

When Using NIS+

Cannot Use NIS+ as Name Service

I/O Error Accessing File Name Service

User Has no DES Credentials

No Permission to Create Table in Data Store

Unable to Determine Name Servers

Errors Trying to Set Up DHCP Table

No Permission to Access dhcp_network Table

Troubleshooting a DHCP Client

Client Cannot Communicate With the Server

DHCP Configurations Received Are Invalid

Isolate the Problem to the Client or Server

Client Cannot Reach DHCP Server

Run Client in Debug Mode

Solaris 2 Client:

DOS Client

Configure the Interface Manually

Run the Server in Debug Mode

Use snoop to Monitor Network Traffic

Look up Error Messages

Problem

Problem

Example 16-1 Sample Output: `pntadm` `-P` `129.146.86.0`

Example 16-2 Sample Output: `dhtadm` `-P`

Using `snoop` to Monitor Network Traffic

To Use `snoop` to Monitor Network Traffic

No Permission to Access `dhcp_network` Table

Use `snoop` to Monitor Network Traffic