|
|
This chapter describes tasks you must perform to allow your CDDM or Cisco Server Suite 1000 system to configure remote hosts via DHCP (Dynamic Host Configuration Protocol) or BootP (Bootstrap Protocol). It contains the following sections:
 | Caution The DHCP/BootP service works only on hosts that have a single IP interface. |
This chapter assumes:
The Bootstrap Protocol (BootP) and Dynamic Host Configuration Protocol (DHCP) let network administrators manage the configuration of remote hosts from a central configuration server. Typically, administrators use BootP and DHCP to assign IP addresses to diskless workstations, X terminals, mobile computers, and computers that connect to the Internet over temporary connections through Internet service providers. BootP and DHCP eliminate the need for computer users to manually configure their systems.
The DHCP and BootP protocols are very similar. In fact, the DHCP protocol is a superset of the BootP protocol. It uses additional state logic and options in the existing BootP transport protocol and packet format. Because DHCP and BootP use the same transport and packets, DHCP servers can take advantage of network router BootP Relay agents that allow BootP servers to serve BootP clients on multiple remote network segments.
CDDM and CSS1000 include a combined DHCP/BootP server that provides both DHCP and BootP service. Although a single server process accommodates both protocols, it maintains separate configuration databases for DHCP and BootP clients, so you can offer different types of configuration data to different types of clients.
The following RFCs describe BootP and DHCP in detail:
The Cisco DHCP/BootP server consists of two separate servers tied with the common functionality of the BootP packet format and transport. The server can accommodate BootP clients with the BootP server configuration, offering the standard set of BootP parameters. This is independent of the DHCP server accommodating the DHCP clients in accordance with the DHCP protocol.
DHCP is essentially an extension of BootP, so DHCP messages are in the same format as BootP messages. Although the Cisco DHCP server can accommodate BootP clients, it can only offer the standard set of BootP parameters, which is a subset of the DHCP parameters.
While the DHCP and BootP servers are very similar in operation, the DHCP server includes the following distinguishing features:
Some clients, such as the Cisco TCP Suite 100 for Windows, send requests that either BootP or DHCP servers can respond to, and accept responses from either type of server. When the DHCP/BootP server receives a DHCP packet (that is, one with a DHCP Message Type option), it checks to see if the client's hardware address is specified in an entry in the BootP database. If so, the DHCP server hands the packet to the BootP server to process the message. If not, then the DHCP server processes the packet as a DHCP packet.
Because the BootP database has to be completely configured manually, the DHCP server interprets the presence of the client's hardware address as an indication that the administrator wants to serve the client via BootP. If you want to include static entries for specific hosts in both the BootP and DHCP databases, however, this behavior may cause problems. You can disable the initial "cross-check" by setting the "dont-bootp" flag in the CSM to 1.
The DHCP protocol is considered a replacement for the BootP protocol. Most modern TCP/IP implementations provide DHCP clients and you can use the DHCP server to configure them. The BootP server is available for configuring hosts with older TCP/IP implementations and legacy equipment.
Although BootP and DHCP clients use several identical messages, DHCP clients go through some additional initial steps to accommodate lease information that does not concern BootP clients.
When a DHCP client starts, it sends a DHCP DISCOVER braoadcast message to UDP port 67 from UDP port 68. The DISCOVER message includes the client's hardware address, optionally a client identifier, and suggested option values. The client sends the lease information to try to renew an existing lease it had with the same server and to get the same configuration data it was previously using, if the data is still appropriate.
When a DHCP server receives a DISCOVER message, it checks its database for a possible match, reserves the appropriate DHCP entry, and responds with an OFFER message sent to the UDP port 68 from the UDP port 67. The OFFER includes the client's hardware address, client identifier from the DISCOVER message, if one was sent, configuration data, and the lease information.
The DHCP client repeats its DISCOVER message until it receives several OFFERs. The DHCP client selects an OFFER based on the individual implementation and broadcasts a REQUEST message indicating the selected OFFER. The client includes the requested options it sent in its initial DISCOVER message.
When the DHCP server that sent the selected OFFER message receives the REQUEST message from the client, it can respond with an acknowledgment, or ACK, message containing the configuration, provided the OFFER is still available. If, for some reason, the OFFER is no longer available, the DHCP server broadcasts a non-acknowledgment, or NAK, message to the client. Similarly, if the client determines that something is wrong with the configuration information in the ACK message, the client can send a DECLINE message to the server to indicate that the IP address given has a problem. The most common reason for a client declining an IP address is that another host on the network is already using the offered IP address.
The DHCP server stores lease information in a "state" file to determine when leases should expire. When the DHCP server starts, it checks the state file to see which leases are still bound to clients and which leases have expired. You can query the Cisco DHCP service for current leases with the Cisco DHCPSTAT utility on UNIX platforms and with the DHCPST32 utility on Windows NT.
Because BootP clients do not use leases, the configuration information provided to BootP clients from the DHCP/BootP server never expires.
DHCP clients attempt to prevent leases from expiring by starting the renewal of the lease when the lease is half expired. If the first renewal attempt fails, the client periodically repeats the renewal until the lease actually expires. If the server happens to be down for a short period of time when the client tries to renew, but it comes up before the lease expires, the client's failure to renew is not fatal because the client's next attempt to renew will succeed. When the lease is 7/8 expired during the renewal process the client starts broadcasting the lease renewal so that servers other than the one that granted the lease can renew the lease. If the lease is not renewed before it expires, the client shuts down its TCP/IP stack and starts broadcasting DISCOVER messages, beginning the configuration process all over again.
BootP clients broadcast "bootrequest" messages that containing their hardware addresses upon startup. The BootP server looks in its configuration database for an entry containing the client's hardware address. If it finds one, it sends a "bootreply" containing the configuration data it is configured for. If it cannot find a match, it does nothing. The "bootrequest" is analogous to the DHCP REQUEST message and the "bootreply" is analogous to the DHCP ACK message.
Some BootP clients send bootrequest messages that specify a boot file. When the BootP server receives such a request, it attempts to locate a local file of the specified name. If the server finds no file of the specified name, it locates a default file, if it is configured to do so. You can specify the server's TFTP directory and bootfile name with the td and bf option tags, on a per-entry basis.
When the DHCP service binds a lease to a client, it stores information about the lease in memory and in a "state file" to which it refers at startup. The state file allows the DHCP server to keep track of outstanding leases even if the system restarts. If the DHCP server cannot access its state file when it starts, it considers the lease available for other clients.
You can remove individual leases manually with the DHCPSTAT utility (see the section, "Examining Current Leases with the dhcpstat Utility") or you can remove all leases by deleting the state file and restarting the DHCP server.
Different vendors' DHCP clients vary in the way they retain or lose lease information. Some clients lose leases when the system restarts; others retain leases when they shut down. Some clients provide controls that let you release the client's lease by sending "release" messages. The Cisco DHCP/BootP server accommodates clients that cancel leases with "release" messages.
In general, if your address space is limited, short lease times will help improve a host's chances of gaining a lease by reducing the number of "abandoned" leases.
Long leases may present a problem for mobile DHCP clients that change location more than once within the chosen lease time. Because some clients do not surrender leases until they expire, the client may restart on a new network with configuration parameters—specifically its IP address—from the previous network.
For example, if a host on subnet A receives a lease that expires in 48 hours, but it shuts down an hour later and restarts 10 hours later connected to subnet B, it will try to renew its old lease. However, because it has moved, one of two things happens:
If you want to let clients and servers on different network segments exchange BootP or DHCP messages, you must configure your routers to perform BootP Relay.
A BootP relay agent is an Internet host or router that accepts—and in some cases modifies— messages from BootP clients, and passes the modified messages to other network segments. DHCP is designed to use the same relay agent behavior specified in the BootP protocol specification.
Every DHCP message provides fields for transferring data between DHCP clients and servers. The DHCP server checks a field called "Relay IP Address" or "GIADDR" to determine the location of the client that sent the message. Clients leave the GIADDR field empty (set to 0.0.0.0) to indicate that the message was sent from the local subnet. If the message passes through a BootP Relay agent, such as a router, before it reaches the server, the router inserts its own IP address on the client's subnet in the GIADDR field. Doing so allows the server to check for a DHCP entry in its database that can accommodate a host on the client's subnet and respond with a suitable DHCPOFFER message.
On Cisco routers, use the Cisco IOS command set dhcp relay to configure the GIADDR, and the show dhcp config command to display the current DHCP Relay Agent configuration.
BootP and DHCP servers obtain client configuration data from database files in which configuration data can be organized in a hierarchy. Traditional BootP and DHCP database files are in plain text format, with configuration parameter values "tagged" by ASCII character pairs that describe the data. Some tags address specific well-known configuration parameters, such as IP addressing and the address of default routers.
RFC 2132 defines a set of standard parameters, or "options," used by BootP and DHCP clients and servers to communicate configuration data. Many of these options correspond directly to an ASCII tag definition in the server configuration file. However, some of the ASCII tags perform actions or establish relationships and do not necessarily match a protocol "option." Although administrators must be familiar with the standard tags and how to organize them, client users never see the tags.
BootP and DHCP support the same set of standard parameters, but DHCP also supports DHCP-specific parameters. The BootP part of the Cisco DHCP/BootP server supports BootP clients with the standard parameters and the DHCP part of the server supports DHCP clients with the standard parameters plus the DHCP specific parameters.
The DHCP/BootP server obtains configuration data from separate DHCP and BootP databases that you manage with the CSM. BootP and DHCP databases organize configuration data in a hierarchy of entries that can "inherit" configuration data from their "parent" entries.
In traditional BootP and DHCP configuration files, option tags were inherited using "tag continuation" (tc) option tags that specify the names of the entries to inherit. The DHCP/BootP server configuration interface provides controls that simplify entry management and inheritance.
Entry names are arbitrary and generally do not affect the client configuration. For example, if you create an entry called "dynamics," the name has no influence over how clients are configured. The only time entry names appear beyond the confines of the DHCP/BootP server is when the DHCP/BootP server adds new hosts to a DNM server database with host names based on an entry name. For details on updating DNS with the DHCP server, see "Automatically Updating DNS with the DHCP/BootP Server."
BootP and DHCP let you reserve "static" entries for specific hosts by including the hosts' hardware address or client identifier. When a client requests configuration, the server looks in its database for an entry that includes the client's hardware address or, for DHCP, the client identifier (which the client sends with its request.)
Although you can configure multiple DHCP servers with identical static entries, you must take precautions to prevent the client from obtaining its IP address while connected to different network segments. If you deploy configuration servers to serve different network segments, make sure that servers do not provide static configuration data to clients on the wrong configuration server by disabling BootP relay agents between the network segments.
When a client receives an IP address, it indirectly is assigned a host name if the IP address is mapped to a host name in DNS. Some DHCP clients, such as the client supplied with Windows 95, let you specify a host name, which the client sends to the DHCP server.
To keep client host names registered in DNS, the Cisco DHCP/BootP server lets you configure the DHCP/BootP server to automatically add DHCP client names to DNS via a DNM server when the clients obtain leases.
To accommodate clients that cannot request specific host names, the DHCP server generates host names based on the DHCP database entry that contains the IP addresses. For example, if you create an entry called admin_mac that contains a pool of addresses for a group of Apple Macintosh computers, the DHCP adds host names such as admin_mac1 and admin_mac2 to DNS.
For details, see "Automatically Updating DNS with the DHCP/BootP Server."
Configuration needs of clients may require more than the standard BootP or DHCP option tag set provides. BootP and DHCP provide two standard ways of extending the configuration data set:
Downloadable configuration files | Because some network devices require large amounts of information or vendor-specific configuration at boot time, BootP and DHCP let you specify the path names of additional configuration files the client can download from TFTP servers. For details on creating downloadable configuration files for a specific system, refer to the vendor's documentation. |
Custom option tags | BootP and DHCP support a set of generic tags that let administrators provide custom configuration data for which clients must be configured to interpret. In traditional BootP and DHCP configuration files, custom option tags are in the form Tn=value, where n is an integer. In the Cisco DHCP/BootP server, you can define custom tags with the CSM (see the section, "Adding Custom Parameters"). |
This section describes how to use the CSM to start, restart, and stop the DHCP/BootP server.
To configure the DHCP/BootP server to start automatically whenever a request is received on the server's port number or to control access to the DHCP/BootP server, see Getting Started with Cisco DNS/DHCP Manager.
To start or restart the DHCP/BootP server:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list. Note that if CSM displays a Restart button instead of a Start button, or if there is a green circle next to the DHCP/BootP server icon, the server is already running.
Step 3 If the server is stopped, click Start. If the server is already running, click Restart.
The DHCP/BootP server reloads the DHCP and BootP databases when it starts. Depending on how you configure your DHCP entries and the dnm-mode parameter, the DHCP/BootP server may also update your DNM server. A Restart button replaces the Start button.
To stop the DHCP/BootP server:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list. Note that if CSM displays a Start button instead of a Restart button, or if there is a red circle next to the DHCP/BootP server icon, the server is already stopped.
Step 3 Click Stop.
Updating DNS to accommodate dynamic hosts requires knowing which hosts have obtained configuration data from the DHCP/BootP server. For every host that obtains its network address from the DHCP/BootP service, there must be an entry in the corresponding DNS zones, including one in the in-addr.arpa zone. When a DHCP client's lease expires, DNS must be updated again to remove entries. Performing these tasks manually can be complicated.
The Cisco DHCP/BootP service eliminates the need to manually coordinate your DNS and DHCP/BootP databases by automatically updating DNS via a DNM server. When properly configured, the DHCP/BootP service behaves as a DNM client, updating the DNM server whenever a host obtains configuration data from the DHCP/BootP server.
Each entry to be used for updating DNS enables the Update DNS (ub option tag) and Insert Host Name (hn option tag) parameters. When these parameters are enabled in an entry, the DHCP/BootP server uses the entry's option tags to update a DNM server.
To manage DNS via your DHCP/BootP server:
Step 1 Create a "dynamic" domain dedicated exclusively for hosts that obtain their configuration data from the DHCP/BootP server and define the dynamic domain's Start of Authority (SOA) data on the DHCP/BootP server. For details, see "Creating a Dynamic Domain on the DHCP Server."
Step 2 Configure your DNM and DNS servers for the "dynamic" domain. For details, see "Configuring Your DNM and DNS Servers for DHCP."
Step 3 Configure the DHCP/BootP server to manage the DNM server. For details, see "Configuring the DHCP Server to Update the DNM Server."
Step 4 Add entries to the DHCP or BootP databases for hosts in the dynamic domain. Be sure to enable the ub and hn option tags in each entry. These tags cause the DHCP/BootP server to use this entry to update a DNM server.
For details on creating entries in DHCP or BootP databases, see "Managing the DHCP and BootP Databases."
To configure the DHCP/BootP server to connect and manage a DNM server when hosts obtain DHCP or BootP configuration data, specify the parameters listed in Table 7-1 in the Parameter tab in the CSM StartUp tab for the DHCP/BootP service.
| Parameter | Description | Default (if any) |
|---|---|---|
Fully qualified domain name of the zone dedicated to hosts that obtain configuration data from the DHCP/BootP server. | (none) | |
Maximum Time-To-Live (in seconds) allowed on each record created via the DNM. | 3 days | |
Time-to-live value to be put into each record created via the DNM server, expressed as a percentage of the lease time. | 10% | |
Refresh time value (in seconds) for the Start of Authority (SOA) record for the dynamic hosts zone. | 900 | |
Retry time value (in seconds) for the Start of Authority (SOA) record for the dynamic hosts zone. | 600 | |
Expire time value (seconds) for the Start of Authority (SOA) record for the dynamic hosts zone. Default value: 6000. | 259200 | |
Minimum TTL (time-to-live) value (seconds) for the Start of Authority (SOA) record for the dynamic hosts zone. | 3600 | |
The hostname of the primary name server for this domain. Used in the NS record for the dynamic domainname. | (none) | |
Email address of the person responsible for the dynamic domain; for example, mgr@yoyodyne.com. This value is put into the SOA record for the dynamic domain and into RP records for the host names the DHCP server generates. | (none) |
Before you can coordinate your DHCP or BootP databases with DNS:
If you need the Cisco DHCP/BootP server to automatically update DNS, you must configure the DHCP/BootP server to connect to the DNM server that will store the zone data and transfer it to DNS servers.
You must decide whether you want to take advantage of the DHCP server's ability to accept hostname suggestions from DHCP clients (referred to as "method 2" DNM update) or if you want to assign predetermined names to DHCP clients when they request configuration data ("method 1" DNM update). Use method 1 if you want to restrict DHCP clients to a predetermined set of host names.
Method 2 updates allow mobile hosts to preserve their fully qualified host names when they connect from different locations, provided they access the same DHCP server. The DHCP server only updates the DNM server when a DHCP client accepts a lease. As a result, the DHCP server does not delete and rebuild the dynamic zone every time it starts and the DNM only contains the names of DHCP clients that currently have leased data.
To configure the DHCP/BootP server to connect to a DNM server, specify the parameters listed in Table 7-2 in the Parameters tab of the StartUp tab for the DHCP/BootP service in the CSM. The parameter settings take effect after you stop and restart the Master Server.
The DHCP server guarantees that names added to the DNM server are unique. If a host name is already in use, the DHCP server generates a unique name dynamically according to the following scheme:
For example, if the entry is called "dhcp-host" and the dynamic domain name is "dyn.yoyodyne.com," the first hostname generated is dhcp-host.dyn.yoyodyne.com. The second hostname generated is dhcp-host1.dyn.yoyodyne.com.
You can view these dynamically generated host names and their corresponding IP addresses in the DNM Browser (see Chapter 5, "Managing Zones with the DNM Browser") and with the DHCPSTAT utility (see the section "Examining Current Leases with the dhcpstat Utility" in this chapter).
Table 7-3 describes parameters that control DHCP/BootP service files. Note that parameter names are not case-sensitive, but file names are.
| Parameter | Description | Default File (if any) |
|---|---|---|
Name of the BootP configuration file. The DHCP/BootP server reads this file when it boots. | ||
Name of the file in which to store BootP information if a dump is requested. | ||
Name of the DHCP configuration file. | ||
Name of the file in which to store DHCP information if a dump is requested. | ||
Name to use for the old checkpoint state. DHCP rebuilds the current state based on the current configuration file and the data contained in the old state file when DHCP is initializing. DHCP renames the existing state file to the name given by the Dhcp- oldstatefile parameter before building the new state checkpoint file. The old file is never referenced again once the server is up. | ||
Name of the file DHCP uses to make sure that client lease information survives across reboots. To completely clear the lease information, delete the file specified. |
You can specify different files for any of the files in the preceding table. You must specify filenames as absolute pathnames.
To configure filename parameters:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 Select the StartUp tab.
Step 4 Select the Parameters tab. The BootP and DHCP parameters 
appear.
Step 5 To change a parameter, make sure the corresponding checkbox is enabled, then enter the desired configuration file's absolute pathname in the corresponding field.
Step 6 Choose Save Configuration from the File menu.
Changes take effect the next time you stop and restart NetControl.
Table 7-4 describes parameters that control the DHCP/BootP service's general behavior using parameters in the StartUp Parameters tab.
DHCP and BootP database records are called "entries." Each entry contains a set of parameters, which are traditionally called "option tags" in DHCP and BootP configuration files. Most DHCP and BootP option tags serve well-known purposes, such as defining a host's IP address, or the location of a file on a TFTP server that provides additional data. Other option tags are "custom," providing a mechanism for distributing data for which there are no dedicated option tags. The DHCP/BootP server accepts some parameters that are Cisco-proprietary extensions.
Although the BootP and DHCP clients use many identical option tags, the CSM keeps separate databases for DHCP and BootP clients.
The CSM lets you:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 To add an entry to the BootP database, select the BootP Config 
tab:
Step 4 To add an entry to the DHCP database, select the DHCP Config 
tab:
Step 5 Enter the name of the new entry in the field below the Entries with Inheritance list.
Step 6 Click Add.
The new entry appears in the Entries with Inheritance list and an empty list of parameters appears in the Option Tags group.
The CSM provides a set of four arrow buttons that let you change the order and inheritance of entries in the Entries with Inheritance list. For details on positioning entries so they inherit parameters from other entries, see "Inheriting Parameters from Other Entries."
To modify the new entry's option tags, see "Changing an Entry's Parameters."
Step 7 Choose Save Configuration from the File menu. The new entry becomes available the next time you restart the DHCP/BootP server.
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 Select the BootP Config or DHCP Config tab.
Step 4 Select one or more entries in the Entries list.
Step 5 Click Delete. When prompted, confirm the delete operation by clicking Yes to delete selected entries one at a time or Yes to All to delete all selected entries at once.
Step 6 Choose Save Configuration from the File menu.
The deleted entry ceases to be available the next time you stop and restart the DHCP/BootP service.
To modify an existing entry's name:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 Select the BootP Config or DHCP Config tab.
Step 4 Select the desired entry in the Entries with Inheritance list.
Step 5 Enter the new entry name in the lower entry field.
Step 6 Click Rename.
Step 7 Choose Save Configuration from the File menu.
The new entry becomes available the next time you restart the DHCP/BootP server.
To change an entry's option tags:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 To modify an option tag in the BootP database, select the BootP Config tab. To modify an option tag in the DHCP database, select the DHCP Config tab.
Step 4 Choose the desired entry in the Entries with Inheritance list. The CSM updates the Option Tags group to show the chosen entry's data.
Step 5 To modify the entry's parameters, choose the desired Option Tags group and enter the parameter values.
Table 7-5 describes the BootP Parameter groups.
| Parameter Group | Description |
|---|---|
Standard | Includes all standard BootP parameters. For details, see Table 7-7. |
Custom | Includes custom parameter definitions. For details, see "Adding Custom Parameters." |
Table 7-6 describes the DHCP Parameter groups.
| Parameter Group | Description |
|---|---|
Includes most basic network configuration parameters. For details, see "Specifying Basic Network Connectivity Parameters." | |
Defines lease times. For details, see "Specifying Lease Information." | |
Includes WINS and NetBIOS parameters for Windows 95 and Windows NT clients. For details, see "Specifying WINS/NetBios Parameters." | |
Includes parameters that affect how the clients configure their network transports. For details, see "Specifying Host IP Parameters." | |
Includes parameters that affect how the clients configure their network interfaces. For details, see "Specifying Interface Parameters." | |
Specifies IP address of network servers to which clients have access. For details, see "Specifying Servers." | |
Includes parameters used by BootP clients. For details, see "Specifying BootP Compatible Parameters." | |
Includes custom parameter definitions. For details, see "Adding Custom Parameters." |
Step 6 Enter the desired value for the option tag in the Value List field. The DHCP/BootP Configuration Editor provides a button for editing option tags that accept multiple values. Click the "..." button. The Edit List dialog box 
appears:
Step 7 Choose Save Configuration from the File menu.
The new values become available the next time you stop and restart the DHCP/BootP service.
The BootP configuration editor lets you configure entries with BootP and provides access to the standard BootP parameters listed in Table 7-7.
| BootP Parameter | Option Tag | Description | Example |
|---|---|---|---|
bf | Boot file downloaded by TFTP to the client at boot time. This file is supplied by the device vendor. The file must exist and be world-readable. If the file is not found, a null file specification is returned. DHCP checks for this file only if the sa tag is set to the server's IP address. | "bootfile.img" | |
bs | Boot file size. If the value is the string "auto" or no value is given, the server automatically determines the size. Otherwise, the specified value is passed verbatim. The size is expressed in 512-byte blocks. | auto or 24 | |
cs | Space-separated list of RFC-865 "quote of the day" or "cookie" server IP addresses, in order of preference. | 192.41.228.92 | |
df | Pathname of a file to which the client dumps its "core" image if it crashes. The path is formatted as a character string consisting of characters from the NVT ASCII character set. | "/usr/local/upload/file.dmp" | |
dn | Domain name. | "yoyodyne.com" | |
ds | DNS server. Space-separated list of domain name server IP addresses. | 192.41.228.65 | |
gw | Space-separated list of IP addresses for routers on the client's subnet. List routers in order of preference. | 128.2.13.1 | |
ha | Hardware address of the client. The format of the hardware address depends on the hardware type (ht). Specify the hardware type (ht) before the hardware address (ha). | 00DD00C88900 | |
hd | Name of the home directory for TFTP files. | "/usr/local" | |
hn | When enabled, the server sends hostnames to its clients. If the DHCP server's Lookup-hostname parameter is enabled (see Table 7-4), the server sends the name it finds in DNS, if one exists for the client's address. If Lookup-hostname is disabled, the DHCP server sends a name based on the entry name. When an entry enables the Insert Host Name parameter, the server sends the contents of the name field (the initial string of characters on each record up to, but not including, the first colon) to the client. If the name field and all the other fields in the response, do not fit in the packet, the name is truncated to just the host name without the domain name (if present). If there is still too much data for the packet, the host name is dropped. If the host field by itself does not fit, the server does not send a name. | (checkbox enabled) | |
ht | Hardware address type. The hardware type must be interpreted before the hardware address (ha). Valid values are the hardware type, expressed as a decimal number as defined by the RFCs or a text string that maps to the hardware type number. See Table 7-8 for the values you can use for this tag. | ethernet or 1 | |
im | Space-separated list of Imagen-type "Impress" server IP addresses. | 192.41.228.92 191.41.228.93 | |
ip | IP addresses of the client. | 192.41.228.11 | |
lg | Space-separated list of MIT-LCS UDP log server IP addresses. | 192.41.228.42 | |
lp | Space-separated list of line printer (LPR) server IP addresses. List in order of preference. | 192.41.228.37 | |
ns | Space-separated list of IEN-116 name server IP addresses. | 192.41.228.77 | |
nt | Space-separated list of NTP time server IP addresses. List in order of preference. | 192.41.228.92 192.41.228.93 | |
rl | Space-separated list of RFC 887 RLP (Resource Location Protocol) server IP addresses, in order of preference. | 192.41.228.19 | |
rp | Pathname of the client's root disk consisting of characters from the NVT ASCII character set. | "/export/john/root" | |
sa | Space-separated list of boot server IP addresses | 192.41.228.222 | |
sm | Specifies the client's subnet mask as per RFC 950. | 255.255.255.192 | |
sw | IP address of the client's swap server. | 192.41.228.92 | |
|
(non-editable) | tc | Identifies an entry from which this entry inherits parameters. To configure inheritance, change the position of entries in the Entries with Inheritance list. For details, see "Inheriting Parameters from Other Entries." | common |
td | Root directory of the TFTP hierarchy. Used to reference part of a directory that may be hidden from the client via the TFTP server. | "/tftp" | |
to | Time offset (in seconds) west of Greenwich Mean Time (GMT) for the client. Table 7-9 lists values associated with common time zones. DHCP uses positive numbers west of GMT and negative numbers east of GMT. | 25200 | |
ts | Space-separated list of RFC 868 Network Time Protocol (NTP) server IP addresses, in order of preference. | 192.41.228.77 | |
vm | "Vendor magic" is always rfc1084. | "rfc1084" | |
yd | Sun NIS ("Yellow Pages") domain name, expressed in characters from the NVT ASCII character set. | "accounting" | |
ys | Space-separated list of IP addresses for Sun NIS ("Yellow Pages") servers in order of preference. | 192.41.228.3 |
Table 7-8 lists the values for the Hardware Address Type parameter (ht option tag) for each supported network interface type.
| Hardware Type Name | Hardware Type Number |
|---|---|
ethernet | 1 |
ethernet3 | 2 |
ether | 1 |
ether3 | 2 |
ieee803 | 6 |
tr | 6 |
token-ring | 6 |
pronet | 4 |
chaos | 5 |
arcnet | 7 |
ax.25 | 3 |
Table 7-9 lists values for the Time Offset parameter (to option tag) for a selection of standard timezones.
The DHCP configuration editor provides access to the most common entry parameters under the Basic group of parameters. Table 7-10 describes the Basic DHCP parameters.
| Parameter | Option Tag | Description | Example Value |
|---|---|---|---|
ip | Space-separated list of IP addresses or address ranges. If an entry contains an ip tag but no ha tag, the DHCP server treats the value as a dynamic address and adds it to the subnet's pool. To specify a range of IP addresses, use a hyphen in the appropriate octet (for example, 192.41.228.11-20). For details on establishing an IP address pool, see "Creating IP Address Pools." | 192.41.228.11-20 | |
sm | Specifies the client's subnet mask as per RFC 950. | 255.255.255.192 | |
gw | Space-separated list of IP addresses for routers on the client's subnet. List routers in order of preference. | 128.2.13.1 | |
ds | Space-separated list of IP addresses of DNS servers that the client can access. List DNS servers in order of preference. | 192.41.228.65 | |
dn | Specifies the domain name that the client should automatically append to host names that are not fully-qualified via the Domain Name System. | "dynamic.yoyodyne.com" | |
hn | When enabled, the server sends hostnames to its clients. The server can send either the name it sends to the DNM server (based on the entry name or the client-requested name) or the name it finds in DNS for the client. To send the same name as the one the DHCP server sends to the DNM server, the entry's Update DNS parameter (ub option tag) must be enabled. The DHCP server's DNM-mode parameter (see Table 7-4) determines whether the client can request a host name. To send the name associated with the client's IP address in DNS, the entry's Update DNS (ub option tag) must be disabled and the DHCP server's Lookup-hostname parameter (see Table 7-4) must be enabled. When an entry enables the Insert Host Name parameter, the DHCP server sends the contents of the name field (the initial string of characters on each record up to, but not including, the first colon) to the client. If the name field and all the other fields in the response, do not fit in the packet, the name is truncated to just the host name without the domain name (if present). If there is still too much data for the packet, the host name is dropped. If the host field by itself does not fit, the server does not send a name. | (check box enabled) | |
|
(Cisco extension) | ub | When enabled, the DHCP/BootP server uses the entry's parameters to update a DNM server. You must also configure the DHCP/BootP server to update a DNM server. For details, see "Configuring the DHCP Server to Update the DNM Server." | (checkbox enabled) |
|
(non-editable) | tc | Identifies an entry from which this entry inherits parameters. To configure inheritance, change the position of entries in the Entries with Inheritance list. For details, see "Inheriting Parameters from Other Entries." | common |
|
(Cisco extension) | sc | Lists a set of subnets to be considered as a single pool. Must be the name of an entry that appears higher in the Entries with Inheritance list. For details on mapping logical IP subnets into a single conceptual subnet, see "Creating Address Pools Over Multiple Logical Network Segments." | subnet100 |
ht | Specifies the network interface (hardware) type of a static client so the server can determine how to interpret the hardware address specified in the Hardware Address (ha) parameter. See Table 7-8 for the accepted values. | ethernet or 1 | |
ha | This tag identifies the hardware address (MAC address) of a client. Use this parameter to reserve specific configuration parameters for a known (static) host. This server requires a corresponding Hardware Address Type (ht) parameter to interpret the hardware address. | 00DD00C88900 | |
ci | Specifies a unique identifier for static hosts in a manner similar to the Hardware Address parameter. DHCP servers use client identifiers to index their database of address bindings. Client identifiers must be unique over a server's administrative domain. You can use any integer value or quoted string for an identifier, but manufacturers often use client hardware addresses as their client identifiers to ensure unique identifiers. When a DHCP client sends a request with a client identifier, the server first searches the database for a match. If the server finds no match, it searches for a match with the hardware address. If neither search results in a match, the server allocates an address from the appropriate address pool. If you add static entries with client identifiers to the DHCP server, make sure either your DHCP clients let you change their identifiers or that you are specify the same value as the client. | 01080020010203 or "johns-pc" | |
in | Lets the server use the entry as a template for responding to DHCPINFORM messages. DHCP clients send DHCPINFORM messages when they obtain IP addresses by a means other than DHCP and need the server to supply the remaining configuration data. When enabled, the Inform Message parameter may specify the name of a message type. If the DHCP server contains no other entries for the specified subnet, the value must be in the form of a dotted decimal address so the DHCP can determine the subnet about which to be informative. | 192.44.231.1 |
The DHCP configuration editor provides access to lease parameters under the Lease Info group of parameters. Table 7-11 describes the Lease Info DHCP parameters.
The DHCP configuration editor provides access to WINS and NetBios parameters under the WINS/NetBIOS group of parameters. Table 7-12 describes the WINS/NetBIOS DHCP parameters.
| Parameter | Option Tag | Description | Example Value |
|---|---|---|---|
wn | Space-separated list of RFC 1001/1002 NBNS name server IP addresses in order of preference. | 192.41.2.87 192.41.2.88 | |
wd | Space-separated list of RFC 1001/1002 NBDD server IP addresses in order of preference. | 192.41.2.87 192.41.2.88 | |
wt | NetBIOS node type for the NetBIOS-over-TCP/IP client expressed as a hexadecimal code. See Table 7-13 for valid codes. | 04 | |
ws | RFC 1001/1002-compliant NetBIOS-over-TCP/IP scope identifier name for the client. | "dynamic.yoyodyne.com" |
Table 7-13 lists wt option tag values and the corresponding NetBIOS node types.
| Node Type | Code |
|---|---|
B Node | 0x1 |
P Node | 0x2 |
M Node | 0x4 |
H Node | 0x8 |
The DHCP configuration editor provides access to parameters that affect how a client configures its network transport under the Host IP group of parameters. Table 7-14 describes the Host IP DHCP parameters.
The DHCP configuration editor provides access to parameters that affect how a client configures its network interface under the Interface group of parameters. Table 7-15 describes the Interface DHCP parameters.
The DHCP configuration editor provides access to parameters that specify network servers under the Servers group of parameters. Table 7-16 describes the Server DHCP parameters.
The DHCP configuration editor provides access to BootP-compatible parameters under the BootP-compatible group of parameters. Table 7-17 describes the BootP-compatible parameters.
| Parameter | Option Tag | Description | Example Value |
|---|---|---|---|
bf | Boot file downloaded by TFTP to the client at boot time. This file is supplied by the device vendor. The file must exist and be world-readable. If the file is not found, a null file specification is returned. DHCP checks for this file only if the sa tag is set to the server's IP address. | "bootfile.img" | |
bs | Default size of the client's boot file. If the value is the string "auto" or no value is given, the server automatically determines the size. Otherwise, the specified value is passed verbatim. The size is a 16-bit integer, expressed in 512-byte blocks. | auto or 24 | |
cs | Space-separated list of RFC-865 "quote of the day" or "cookie" server IP addresses, in order of preference. | 192.41.228.92 | |
df | Pathname of a file to which the client dumps its "core" image if it crashes. The path is formatted as a character string consisting of characters from the NVT ASCII character set. | "/usr/local/upload/file.dmp" | |
ef | File name, retrievable via TFTP, which contains information which can be interpreted in the same way as the 64-octet vendor-extension field within the BootP response, with the following exceptions: the length of the file is unconstrained; all references to Tag 18 (i.e., instances of the BootP Extensions Path field) within the file are ignored. | "extension.cnf" | |
hd | Name of the home directory for TFTP files. | "/usr/local" | |
im | Space-separated list of Imagen-type "Impress" server IP addresses, in order of preference. | 192.41.228.92 191.41.228.93 | |
ns | Space-separated list of IEN-116 name server IP addresses, in order of preference. For most clients, use the ds tag instead of the ns tag. | 192.41.228.77 | |
rl | Space-separated list of RFC 887 RLP (Resource Location Protocol) server IP addresses, in order of preference. | 192.41.228.19 | |
rp | Pathname of the client's root disk consisting of characters from the NVT ASCII character set. | "/export/john/root" | |
sa | Space-separated list of boot server IP addresses. | 192.41.228.222 | |
sw | IP address of the client's swap server. | 192.41.228.92 | |
td | Root directory of the TFTP hierarchy. Used to reference part of a directory that may be hidden from the client via the TFTP server. | "/tftp" | |
to | Time offset (in seconds) west of Greenwich Mean Time (GMT) for the client. Table 7-9 lists values associated with common time zones. DHCP uses positive numbers west of GMT and negative numbers east of GMT. | 25200 | |
ts | Space-separated list of RFC 868 Network Time Protocol (NTP) server IP addresses, in order of preference. | 192.41.228.77 |
Most DHCP and BootP options tags serve well-known purposes, such as defining a host's IP address, or the location of a file on a TFTP server that provides additional configuration data. Other option tags are "custom," which means that they provide a mechanism for distributing data for which there is no dedicated option tag. The DHCP and BootP configuration editors provide access to custom parameters via the Custom parameter group.
Each custom parameter has an assigned number and a value in ASCII text enclosed in quotes or in binary data expressed as hexadecimal digits.
When expressing binary data that represents short or long values, be sure to check the byte order to compensate for the difference between the native operating system's byte order and network byte order. For values with known tags, the server can convert between the two. For values in generic tags, however, the server cannot tell the difference between a four-byte binary string and an unsigned long value.
To add a custom parameter:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 To modify an option tag in the BootP database, select the BootP Config tab. To modify an option tag in the DHCP database, select the DHCP Config tab.
Step 4 Choose the desired entry in the Entries with Inheritance list. The CSM updates the option tag area to reflect the chosen entry's data.
Step 5 Choose Custom from the Group pop-up menu in the Option Tags group.
Step 6 Locate an empty parameter line or create one by clicking the Add button in the Option Tags group.
Step 7 Enter the generic tag's number and value in the appropriate fields.
Alphanumeric values must be enclosed in quotes.
Step 8 Choose Save Configuration from the File menu.
The new values become available via the DHCP/BootP server the next time you restart the DHCP/BootP server.
The DHCP/BootP service lets you create entries that inherit option tags from other entries.
For example, you might create an entry called "admin_net" that defines basic networking parameters, such as subnet mask, default gateway, and DNS server for a specific network. You could then create entries for a set of PCs (for example, pc_chris and pc_kim) that define parameters that are unique to each PC, such as their IP and hardware addresses, and then configure each entry to inherit the admin_net entry's parameters. If the admin_net DNS server or router changes address, you only have to change the admin_net entry instead of each individual PC entry.
To inherit another entry's option tags:
Step 1 Start the CSM.
Step 2 Choose DHCP/BootP from the Available Services list.
Step 3 To modify inheritance in the BootP database, select the BootP Config tab. To modify inheritance in the DHCP database, select the DHCP Config tab.
Step 4 Select the entry that needs to inherit another entry's parameters in the Entries with Inheritance list. The CSM updates the Option Tags group to reflect the chosen entry's data.
Step 5 Using the up and down arrow buttons, move the entry directly under the entry from which it will inherit parameters. For example, position pc_chris directly below admin_net.
Step 6 To inherit the entry immediately above it in the Entries with Inheritance list, click the right arrow button. The Entries with Inheritance list indents entries to indicate they inherit parameters from the entry above them. For example, if the entry "pc-chris" needs to inherit parameters from the entry "admin-net," they should appear as 
follows:
Step 7 To override inherited parameter values, enter a new value in the inheriting entry.
Step 8 Choose Save Configuration from the File menu.
The new values become available the next time you restart the DHCP/BootP server.
There are three ways to configure DHCP to assign IP addresses to remote hosts from a pool of addresses:
You can create an IP address pool by configuring a set of DHCP configuration file entries that specify IP addresses and host names (using the ip and hn option tags, respectively), but without specifying hardware addresses with ha option tags. You must also make sure that names specified in the hn option tag also exist in DNS. To coordinate DHCP names with DNS, do one of the following:
If you disable both the Update DNS parameter (ub option tag) and the Insert-hostname parameter, the DHCP server sends the client the name of the entry for its host name (for example, dhcp_host1 through dhcp_host8 in the following example), but it does not check DNS to make sure the name is valid.
For example, to configure a pool of eight IP addresses on a subnet:
Step 1 Create an entry named "subnet20" that defines a set of configuration parameters common to all hosts on the subnet20 subnet. Use the following option tags:
| Option Tag | Value |
|---|---|
hn | enabled |
gw | 172.16.20.1 |
ds | 172.16.20.100 172.16.20.200 |
sm | 255.255.255.0 |
Step 2 Create entries for each host named "dhcp_host1" through "dhcp_host8" that define the names and IP addresses for the eight hosts. For example, the dhcp_host1 entry might specify 172.16.20.103 as the IP address parameter.
Step 3 Use the arrow keys in the Config tab to position the eight host entries so they inherit the subnet20 entry's parameters.
The host name lookup is performed at the time of actual address assignment.
You can create an IP address pool by configuring a single entry with a single host name, a list of IP addresses or address ranges, and no hardware address. Although this method produces concise configuration file entries, it requires configuring the DHCP server with the Lookup-hostname parameter and configuring the hosts in DNS before starting the DHCP server. If you use the ub tag, however, you need not create host names (see "Automatically Updating DNS with the DHCP/BootP Server").
For example, to configure a pool of eight IP addresses on a subnet without defining any host names:
Step 1 Create an entry named "subnet20" that defines a set of tags common to all hosts on the subnet20 subnet. Use the following option tags:
| Option Tag | Value |
|---|---|
hn | enabled |
gw | 172.16.20.1 |
ds | 172.16.20.100 172.16.20.200 |
sm | 255.255.255.0 |
Step 2 Create a single entry with an arbitrary name such as "dhcp_hostx" that defines the range of IP addresses for the eight hosts. For example, the dhcp_hopstx entry might specify 172.16.20.201-208 as the IP address parameter.
Step 3 Use the arrow keys in the Config tab to position the dhcp_hostx entry so it inherits the subnet20 entry's parameters.
The host name lookup is performed at the time of actual address assignment.
The DHCP protocol does not provide specific guidelines for pooling addresses from multiple logical subnets that reside in a single physical network segment. While the method described in this section works well with Cisco routers configured with BootP forwarders, there is no guarantee that other BootP forwarders will behave in the same way.
The DHCP/BootP server lets you create a pool of IP addresses that spans multiple logical subnets, using the sc (segment continuation) option tag. This is useful when you need to pool addresses from different networks, such as two class C networks or a Class B and a Class C network.
For example, suppose you need to offer a pool of 400 addresses and your network is composed of two class C networks. The sc option tag lets you combine the two subnets and put all 400 addresses in the pool.
The sc option tag is necessary because of the following general problem with the DHCP protocol in a network configuration with multiple logical subnets on a single physical network. BootP forwarders put the IP address of the interface that heard the DHCP or BootP broadcast packet into the GIADDR field of the request packet forwarded to the DHCP server. The DHCP server uses this field to determine the IP subnet where the packet originated. The address placed in the GIADDR field is called the "primary interface address" and can be any one of the addresses on the interface. Other subnets must be configured as secondaries on the primary interface. The DHCP server can only assign addresses from pools associated with the primary subnet, not from other pools on the network segment.
To map the logical subnets into one conceptual subnet, you define an entry for each logical subnet and tie these entries together with sc option tags. The first logical subnet entry in the list of entries contains no sc option tag; this will be entry to which the other entries point. The other subnet entries contain the sc option tag pointing to the first entry and must follow the first entry in the list of entries. Each entry for a logical subnet specifies an IP address or a pool of addresses on the same network segment. All addresses in the subnet entries are available for all DHCP requests from that network segment. DHCP automatically determines that the packet came from one of those subnets.
You must also add sc option tags to entries for "static" hosts (that is, entries for hosts with specific hardware addresses) on subnets that are part of the conceptual subnet. Static host entries require sc option tags to indicate to the DHCP server that the static IP address is actually on the network segment indicated by the GIADDR field.
In the following example, logical IP subnets 248, 249, and 250 share the same network segment. Three hosts with known hardware MAC (media access) addresses reside on the 251 and 252 subnets.
Step 1 Create an entry named "yoyodyne-subnet" that contains common data for all hosts using the following option tag values:
| Option Tag | Value |
|---|---|
ds | 172.16.192.52 172.16.72.2 |
hn | enabled |
ld | 300 |
lh | 3000 |
dn | ns1.yoyodyne.com |
Step 2 Create an entry for one of the logical subnets. For example the "subnet248" entry might contain the following option tag values:
| Option Tag | Value |
|---|---|
gw | 172.16.248.2 |
ip | 172.16.248.50-99 |
Step 3 Use the arrow keys in the Config tab to position the subnet248 entry so it inherits the yoyodyne_subnet entry's parameters.
Step 4 Create an entry for the 249 subnet with the following option tags:
| Option Tag | Value |
|---|---|
gw | 172.16.249.2 |
ip | 172.16.249.3-100 |
sc | subnet248 |
Step 5 Use the arrow keys in the Config tab to position the subnet249 entry so it inherits the yoyodyne_subnet entry's parameters.
Step 6 Create an entry for the 250 subnet with the following option tags:
| Option Tag | Value |
|---|---|
gw | 172.16.250.2 |
ip | 172.16.250.30-55 |
sc | subnet248 |
The entry pointed to by the sc option tag can be any of the three subnets; in this case, it is subnet 248. The entries for the other two subnets follow the entry for subnet 248 and contain sc option tags pointing to the subnet 248 entry.
Step 7 Use the arrow keys in the Config tab to position the subnet250 entry so it inherits the yoyodyne_subnet entry's parameters.
Step 8 Create entries for the three hosts with known hardware addresses.
| Option Tag | Value |
|---|---|
gw | 172.16.251.2 |
ip | 172.16.251.10 |
ha | 080020a0b3c9 |
sc | subnet248 |
| Option Tag | Value |
|---|---|
gw | 172.16.251.2 |
ip | 172.16.251.11 |
ha | 080020809c3d |
sc | subnet248 |
| Option Tag | Value |
|---|---|
gw | 172.16.251.2 |
ip | 172.16.252.201 |
ha | 080020f3c2be |
sc | subnet248 |
Step 9 Use the arrow keys in the Config tab to position the ceo_mac, vp_john_pc, and net_admin_cray4 entries so they inherit the yoyodyne_subnet entry's parameters.
CDDM includes a command-line utility called dhcpstat that lets you monitor and selectively remove outstanding leases of a DHCP server running locally or on a remote host.
To start dhcpstat on UNIX systems, log in as root (or equivalent) and execute the following command from a shell prompt:
% install_dir/CSCOddm/bin/dhcpstat options
To start dhcpstat on Windows NT systems, log in as Administrator and enter the following command from a DOS prompt:
install_dir\dhcpst32 options
where install_dir is the directory in which CDDM is installed. And options is a string of one or more command-line options from Table 7-18.
The following examples assume you have modified your PATH environment variables to include the CDDM bin directory. These examples are for the UNIX version of the utility. The Windows NT version, dhcpst32, resides in the directory in which CDDM is installed.
To turn on error, notice, informational, and debug logging on a remote DHCP server, named netsrvr execute either of the following commands:
dhcpstat -host netsrvr -debug 15
dhcpstat -h netsrvr -l 15
To reload the DHCP database and configuration files, and display detailed lease information for two clients, with addresses 165.83.213.238 and 165.83.213.239.
dhcpstat -reload -client 165.83.213.238 -client 165.83.213.239
To display detailed lease information from the remote DHCP server named netsrvr for any leases assigned to the client with hardware address "00:c0:af:11:98:9c":
dhcpstat -host netsrvr -haddr 00:c0:af:11:98:9c
Posted: Tue Dec 17 18:49:06 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.