|
|
Dynamic Host Configuration Protocol (DHCP) is an industry-standard protocol for automatic assignment of IP addresses and configuration information to computers. DHCP uses a client/server model for address allocation. As administrator, you can configure one or more DHCP servers to provide IP address assignment and other TCP/IP-oriented configuration information to your computers. DHCP frees you from having to assign an IP address to each client manually.
DHCP is specified by Internet Engineering Task Force (IETF) Requests for Comments RFC 1542, RFC 2131, and RFC 2132.
This chapter describes the following topics:
The Network Registrar DHCP server provides you with a reliable method for automatically assigning IP addresses to hosts on your network. You can define DHCP client configurations, and use the Network Registrar database to manage assignment of client IP addresses and other optional TCP/IP and system configuration parameters. The TCP/IP parameters that can be assigned include:
The Network Registrar database is automatically created when you install the DHCP server software. You add data to the Network Registrar database through the graphical user interface (GUI), ntwkreg, or the command line interface (CLI), nrcmd, as you define DHCP scopes and policies.
To create a scope, supply the following information:
Every scope must have a policy. Policies are the way you define lease duration and other configuration parameters, called DHCP options. You can define specific policies for specific scopes or you can use the system default policy. For more information about the system default policy, see the "DHCP Policies" appendix.
Policies are especially useful if you have multiple scopes, because you need only define a policy once and then you can use it for all the similar scopes in your network.
There are two types of policies: the system default policy and user-defined policies.
Network Registrar checks the policies when a client requests an option. It begins with the user-defined policy associated with the scope, and if it has not found the answer it checks the system default policy. For more information about how Network Registrar determines options at run-time, see the "Creating a New Policy" section later in this chapter.
Configure DHCP options to supply configuration parameters automatically, such as the name of your domain, the name and IP address of your domain name server, the IP addresses for routers on the client's subnet, and other attributes to DHCP server clients. For more information about DHCP options, see the "DHCP Options" appendix.
Use the Network Registrar client or client-class facility to provide differentiated services to users accessing a common network. You can group your user community based on administrative criteria, and then ensure that each group of users receives the appropriate class of service when they access the network.
Although the Network Registrar client-class facility can be used to control any configuration parameter, it is most commonly used to control the following:
In order to understand how to apply client-class processing, it is helpful to know how the DHCP server handles client requests.
When a client requests an IP address from its DHCP server, the server performs three tasks:
To choose an address for the client, the DHCP server determines the client's subnet (based on the request packet contents), and finds an appropriate scope for that subnet.
If you have multiple scopes on one subnet, or multiple scopes on several IP subnets (multinetting), the DHCP server may choose among these scopes in a round-robin fashion. After the server has selected a scope, it then chooses an available IP address from that scope.
DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. These configuration parameters are called DHCP options.
After the DHCP server has selected an IP address for the requesting host, it needs to supply the appropriate options. Network Registrar uses policies to group options. There are two types of policies: scope-specific and system default.
For each DHCP option the client requests, the DHCP server searches for the value of that option. If the scope-specific policy contains the option, it returns the value to the host and stops searching. If the scope-specific policy does not contain the option, the DHCP server looks in the system default policy. If the system default policy contains a value for that option, it returns the value and stops searching. If neither policy contains the option, the DHCP server returns no value to the client and logs an error. The DHCP server repeats this process for each of the requested options.
For example, if a host requests options A, B, and C, and the scope-specific policy contains a value for option A and the system default contains a value for option A and B, the host gets the value for option A from the scope policy, the value for option B from the system policy, and an error because there is no value for option C.
If you have enabled dynamic DNS update, Network Registrar enters the client's name and address in the DNS host table. The client's name can be one of the following:
You can accept the default client name, or configure another. For more information about using a prefix, see the "Configuring for the Scope" section later in this chapter.
With normal DHCP processing, you cannot ensure that requesting hosts receive the appropriate class of service. You only can provide them with a suitable IP address based on their subnet. The Network Registrar client-class facility allows you to fine-tune host access.
Use the client-class facility to control the IP address a client receives, the type of DHCP options, the policy, or the FQDN. You can configure any of these features independently or in conjunction with each other.
To use the client-class facility for IP address selection, first create scope selection tags. These are text strings that you use to distinguish types of service. For example, if you wanted to divide your user community into users who could access the Internet (who receive valid IP addresses) and users who are restricted to the in-house network (who receive private IP addresses, such as net10 addresses), you could create the scope selection tags internal and external. For more information about defining scope selection tags, see the "Defining Scope Selection Tags" section later in this chapter.
After you create scope selection tags, associate them with the corresponding scopes. To continue the above example, you would associate the internal scope selection tag with scopes that contained private addresses, and the external scope selection tag with scopes that contained valid IP addresses. For more information about how to add selection tags to scopes, see the "Choosing Scope Selection Tags" section later in this chapter.
You then could assign all your clients to either include or exclude the appropriate selection tags or you could create two classes of users to group your user community into categories. For example, you could create a client-class called internal-users and include the scope selection tag internal and exclude the tag external, and the client-class external-users and include the scope selection tag external and exclude the tag internal. For more information about how to apply the scope selection, see the "Editing Scope Selection Criteria" section later in this chapter.
If you are using client-classes, the next step is to assign clients to these classes. For example, you would enter the names (MAC addresses) of all the users who were restricted to the internal network into the client-class internal-users, and all the users who could access the Internet into the client-class external-users. For more information about how to add clients, see the "Adding a Client" section later in this chapter.
When you have enabled the client-class facility for the Network Registrar DHCP server, the request processing performs the same three tasks of assigning IP addresses, options, and domain names, but with differences.
To choose an address for the client, the DHCP server determines the client's subnet just as in regular DHCP processing. The DHCP server then checks to see if there is a client entry for the user in its database:
The scopes must have addresses on the client's subnet, and can include secondary subnets. The scopes must have all the selection tags in the inclusion list, and have none of the selection tags in the exclusion list. The DHCP server assigns an available IP address from an appropriate scope, and uses a round-robin approach if there are several appropriate scopes.
In regular DHCP processing there were two policies to check, with client-class there may be as many as four:
The DHCP server checks each of these policies and uses the first value it finds. If the DHCP server cannot find the value for the requested option in any of these policies, it returns an error. The DHCP server repeats this process for each client-requested option.
If you have enabled dynamic DNS updates, Network Registrar updates the DNS server with the client's host name and IP address. When using the client or client-class facility, specify one of the following options:
For more information about the different types of host names that you can specify, see the "Adding a Client-Class" section later in this chapter.
When configuring a DHCP server, you must configure the server properties, policies, and dynamic DNS updates.
The dhcp-interface command lets you add, remove, and list the IP addresses of your server's hardware cards (such as Ethernet or token ring), also called NICs (Network Interface cards). Interfaces are named with the IP address and net mask for the physical device.
You can list the interfaces to provide either an explicit list of interfaces that the DHCP server should listen on, or an explicit list of interfaces that the DHCP server should not listen on.
If you enable discover-interfaces, the DHCP server uses the OS platform support to enumerate all of the active interfaces on the machine, and (unless there is an interface configuration with the ignore feature enabled) attempts to listen on each of these.
If you disable discover-interfaces, the DHCP server consults the interface list for all interfaces that do not have the ignore feature enabled, and attempts to listen on each of these.
Use the dhcp-interface command to configure two different interfaces.
nrcmd> dhcp-interface 192.168.1.12/24 create nrcmd> dhcp-interface 10.1.2.3/24 create
To cause Network Registrar not to look at one interface, type the following. You must have created the interface specification before you can set it to be ignored.
nrcmd> dhcp-interface 10.1.2.3/24 set ignore=true
A policy consists of the following components:
To define appropriate values for lease times, you should consider the required network configuration information as well as the frequency of the following events for your network:
All of these events can cause IP addresses to be released by the client or can cause the leases to expire at the DHCP server. Consequently, the IP addresses are returned to the free-address pool to be reused.
If many changes occur on your network, you should assign a short lease time, such as four days (but you do not want to have the lease expire over a weekend which causes the DNS name to disappear and might cause performance problems). With a short lease time, the address assigned to a client that leaves the subnet can be reassigned quickly to new DHCP client computers requesting TCP/IP configuration information.
Another important factor is the ratio between connected computers and available IP addresses. For example, the demand for reusing addresses is low in a network where 40 systems share a C class address (with 254 available addresses). A long lease time, such as two months, would be appropriate in such a situation. If 240 to 260 computers can be connected at one time, the demand for leases will be high. In this situation you should try to configure more addresses. Until you do, keep the DHCP lease time to under a hour.
Although you can create policies that have permanent leases, you should use them carefully. Even in a relatively stable environment, there is a certain amount of turnover among clients. At a minimum, portable computers might be added and removed; desktop computers might be moved from one office to another; and network adapter cards might be replaced. If a client with a permanent lease is removed from the network, the IP address cannot be reused until the server is reconfigured. A better option would be to create a lease with a long duration, such as six months. A long lease duration ensures that addresses are ultimately recovered without administrator intervention.
Network Registrar has a system default policy that applies to all scopes. You get the default policy when you create a scope, unless you select or create your own policy. You can override the default policy's parameters in your own policy, that is, the more specific (scope) policy takes precedence when it contains information that is also in the more general (system default) policy. For more information about the system and scope default policies, see the "DHCP Policies" appendix.
Step 1 Use the policy create command to create the policy.
nrcmd> policy CompanyB create
Step 2 Use the policy set command to set the appropriate policy options. For example, to set the grace period to one day, type:
nrcmd> policy set CompanyB grace-period=1d
Use the policy enable command to enable the permanent-leases feature.
nrcmd> policy CompanyB enable permanent-leases
Use the policy delete command to delete a policy.
nrcmd> policy CompanyB delete
Use the policy set command to change the value of a property. For example, to change the grace period from one day to two days, type:
nrcmd> policy CompanyB set grace-period=2d
You can set individual option values with the setOption command, unset option values with the unsetOption command, and view option values with the getOption and listOptions commands. When you set an option value, the DHCP server replaces any existing value or creates a new one, as needed, for the given option name.
Use the policy setOption command to add or edit an option. For example, to specify the lease time in a scope, type:
nrcmd> policy CompanyB setOption dhcp-lease-time 3600
The setOption command requires a space (not an equal sign) before the property value.
Use the policy unsetOption command to remove an option from a policy. For example, to remove the dhcp lease time in a scope, type:
nrcmd> policy CompanyB unsetOption dhcp-lease-time
For more information about how DHCP handles options, see the "DHCP Request Processing" section earlier in this chapter.
If you plan to use dynamic DNS update, you must configure both the DHCP and DNS servers. For more information about dynamic DNS update, see the "Configuring Dynamic DNS Update" section later in this chapter.
You do not need to change the following parameters; they are described here for your reference:
nrcmd> dhcp set max-dns-packets=400
nrcmd> dhcp set max-dns-retries=6
nrcmd> dhcp set max-dns-renaming-retries=6
nrcmd> dhcp set dns-timeout=3600
nrcmd> dhcp set max-dns-ttl=3600
The scope-selection-tag command lets you define tags that are added to the scope selection tag list. After you have defined scope selection tags, you can associate them with scopes, clients, and client-classes.
You use client-classes by doing the following tasks:
To use client-class, you must enable it for the DHCP server. Enabling client-class processing causes the DHCP server to assign the client to an IP address from a matching scope. For every DHCP packet the server receives, it examines the client and the client-class information, and determines if this client has any stored information. If it does, the server acts on the information. If not, the processing continues just as if it were not enabled.
If you do not enable client-class processing, the Network Registrar DHCP server provides client leases based solely on their location in the network.
Use the dhcp command client-class feature to enable client-class processing.
nrcmd> dhcp enable client-class
Network Registrar lets you add up to 30 scope selection tags. When the DHCP server configures itself, it checks the number of scope selection tags defined for any network. A network in this context is the aggregation of all of the scopes that are related to a particular subnet. This includes all of the scopes that belong together (because they share a common network number and subnet mask) and all of the scopes that are related to one of these through the use of the primary scope reference. Thus, within all of the scopes that make up a network, there can be no more than 30 scope selection tags.
When the DHCP server reads a client entry (from the local database or from LDAP), the server checks its scope selection inclusion and exclusion criteria against the scope selection tags defined for the scopes on this network. If the client entry references tags that are not present in any scope in the network, then how the server handles the tags depends on whether the reference is to included or excluded tags. If the reference is for excluded tags, then the tag will have no effect. If the reference is for included tags, then the server determines that there is no acceptable scope on that network for this client.
Use the scope-selection-tag create command to create a selection tag.
For example, to create the tag internal type:
nrcmd> scope-selection-tag internal create
To debug selection tags you can use the dhcp command log-settings properties, particularly client-criteria-processing and unknown-criteria. For more information, see the Network Registrar CLI Reference Guide.
Use the scope-selection-tag delete command to delete a selection tag. For example, to delete the selection tag internal, type:
nrcmd> scope-selection-tag internal delete
Use the scope-selection-tag list command to list selection tags.
nrcmd> scope-selection-tag list
The client-class command allows you to create client-classes and apply a set of properties to groups of clients.
Use the client-class create command to create a client-class. For example, to create the client-class internal-users, type:
nrcmd> client-class internal-users create
Use the client-class set command to set the inclusion scope selection criteria. For example, to include the scope selection tag internal in the client class internal-users, type:
nrcmd> client-class internal-users set selection-criteria=internal
Use the client-class set command to set the exclusion scope selection criteria. For example, to exclude the previously created scope selection tag external in the client class internal-users, type:
nrcmd> client-class internal-users set selection-criteria-excluded=external
Network Registrar handles inclusion and exclusion for the applicable subnet in the following manner:
For example, assume three scopes, A, B, and C, with the following attributes A/red, B/blue, C/blue,green. If a client-class specified inclusion of red, then the client would get an address from scope A. If a client-class specified inclusion of blue, then the client would get an address from either scope B or C. If a client-class specified inclusion of blue and exclusion of green, then the client would get an address from scope B.
Use the client-class delete command to delete a client-class. For example, to delete the client-class internal-users, type:
nrcmd> client-class internal-users delete
To debug client problems, you can use the dhcp command log-settings properties, particularly client-detail. For more information, see the Network Registrar CLI Reference Guide.
Use the client-class set command to edit the properties of the clients. For example, to change the policy that the client-class uses, type:
nrcmd> client-class internal-users set policy-name=long
When you create clients, specify their MAC address, the client-class to which they belong (if any), the host name, domain name, the policy, and the action properties for all the clients in the cluster.
A client inherits the properties from its client-class, which you may choose to override or supplement by specifying different ones for the client.
Step 1 Use the client create command to create a client.
Specify the client by MAC address.
nrcmd> client 1,6,02:02:02:02:02:02 create
Step 2 Use the client set command to set the following client properties:
For example, to set the policy, type:
nrcmd> client 1,6,02:02:02:02:02:02 set policy-name=CompanyB
Use the client show command to display properties of a specific client. For example, to display the client 1,6:03:03:03:03:03:03, type:
nrcmd> client 1,6:03:03:03:03:03:03 show
Use the client list command to display properties for all the clients.
nrcmd> client list
Use the client set command to set new scope selection criteria. The tags must already have been created with the scope-selection-tag command.
nrcmd> client 1,6,02:02:02:02:02:02 set selection-criteria=laptop
Use the client set command to change the value of a property. For example to change the client's client-class-name, type:
nrcmd> client 1,6:03:03:03:03:03:03 set client-class-name=external-users
Use the client delete command to delete a client.
nrcmd> client 1,6:03:03:03:03:03:03 delete
If you move a DHCP client machine from one subnet to another, you need either to reboot the machine when it arrives on the new subnet, or explicitly release and reacquire a lease using winipcfg.exe (for Windows 95), or ipconfig /release and ipconfig /renew (for Windows NT). You must do this because until the lease expires on the machine that was moved, it will be using an IP address that is incorrect for the network on which it is placed. You are most likely to see this situation when you move laptop computers.
You can use the dhcp commands set, get, unset, and show to assign and retrieve values from the DHCP's name-value properties. You can set the following parameters:
nrcmd> dhcp set max-dhcp-responses=400
nrcmd> dhcp set max-dhcp-requests=400
nrcmd> dhcp set max-ping-packets=250
nrcmd> dhcp enable hardware-unicast
nrcmd> dhcp enable cisco-dhcp-proxy
nrcmd> dhcp enable defer-lease-extensions
nrcmd> dhcp set last-transaction-time-granularity=1800
In addition to assigning values to pre-defined DHCP options, you can also create your own options. These options are called custom options.
You can add, edit, or delete a custom option. After you have defined a custom option, use the policy setOption, unsetOption, getOption, and listOptions commands to associate options with policies, and to manipulate or display their values.
Use the custom-option create command to create a custom option. For example, to create the option red, mapped to number 100, and of type IPADDR, type:
nrcmd> custom-option red create 100 IPADDR
Use the custom-option set command to change the option's description. For example, change the description to "This option applies to all external users," type:
nrcmd> custom-option red set desc="This option applies to all external users"
You cannot change an option's number but you can delete the option and recreate it. Also, use caution when changing any properties except the description. Changing an option's property can have unexpected side-effects if the option is used in any policies.
Use the custom-option delete command to delete an option. For example, to delete the custom option red, type:
nrcmd> custom-option red delete
After you have defined a custom option, you can use the show command to display the values of all the custom options properties, or the get command to display individual properties. For more information about these options, see the "DHCP Options" section earlier in this chapter.
Use the custom-option show command to show an option's values. For example, to show the custom option red, type:
nrcmd> custom-option red show
Use the custom-option list command to list options.
nrcmd> custom-option list
You should only need to set debug settings if you have been instructed by Technical Support.
Use the server command to specify the debugging level. The following example provides packet trace logging.
nrcmd> server DHCP setDebug VX=5
Use the server command to unset debugging.
nrcmd> server DHCP unsetDebug
You probably should install more than one DHCP server so that if one server fails, the DHCP clients can continue to obtain IP addresses. Because the DHCP protocol does not provide a way for DHCP servers to cooperate in ensuring that assigned addresses are unique, you must divide the IP address pool among the DHCP servers to prevent duplicate address assignment.
You can configure two DHCP servers to distribute the load and handle the leases if the first DHCP server goes down. You must configure the second DHCP server on a different cluster than the first server.
After you have set up both servers, the local DHCP server will respond to requests from local DHCP clients most of the time, while the remote DHCP server will assign addresses to clients on the other subnet only when the local server is unavailable or without addresses.
Any router that supports BOOTP relay usually has an IP address that points to the DHCP server. For example, if you are using a Cisco router, it uses the term ip helper address, which contains an IP address for a specific machine. In this case, you would use this address to forward all BOOTP (and therefore DHCP) broadcast packets. You should make sure that you have configured this address on the router closest to your desktop machine.
BOOTP (BOOTstrap Protocol) was originally created for loading diskless computers. It was later used to allow a host to obtain all the required TCP/IP information to use the Internet. BOOTP allows a host to broadcast a request onto the network, and obtains information required from a BOOTP server. The BOOTP server is a computer that listens for incoming BOOTP requests and generates responses from a configuration database for the BOOTP clients on that network. BOOTP differs from DHCP in that it has no concept of lease or lease expiration. All IP addresses allocated by a BOOTP server are permanent. You can configure Network Registrar to act like a BOOTP server. In addition, although BOOTP normally requires static address assignments, you can choose to either reserve IP addresses (and therefore use static assignments) or have IP addresses dynamically allocated for BOOTP clients. When you move or decommission a BOOTP client, you can reuse its lease, simply by using the lease force-available command.
When you configure the DHCP server to return a BOOTP packet, be aware that BOOTP requires information in the DHCP packet in fields other than the option space. BOOTP devices often need information in the file (the bootfile), siaddr (the server's IP address), or sname (server's host name) fields of the DHCP packet (see RFC 2131).
Every Network Registrar DHCP policy has fields that allow you to configure the information you want returned directly in the file, siaddr, or sname fields.
Network Registrar's DHCP server also supports a configuration parameter that allows you to configure the policy options and determine which of the fields' file, sname, or siaddr you want returned to the BOOTP device.
Network Registrar supports an analogous configuration parameter that allows you to configure which options and which of the fields: file, sname and siaddr you want returned to the DHCP client. This is in addition to any options requested by the DHCP clients in the dhcp-parameter-request option in the DHCP request.
Thus, you can configure both the BOOTP and DHCP response packets appropriately for your devices.
Step 1 Decide the values that you want in the BOOTP packet reply fields:
Step 2 Decide the list of options and their values that you want returned to the BOOTP client.
Step 3 Set the following values in the policy you want associated with the BOOTP request:
Step 4 Enable the associated scope or scopes for BOOTP processing.
Enable dynamic BOOTP processing if you want to have this scope provide an address for any BOOTP client that requests one. If you do not enable dynamic BOOTP, you will need to make reservations for each BOOTP client for which you want this scope to provide an address.
Step 1 Set the policy fields.
Specify the boot-reply options as a comma-separated list of strings. Specify the name of the option or field. The options have regular names, whereas the fields have names such as packet-siaddr, packet-file-name, and packet-server-name.
nrcmd> policy MyPolicy create nrcmd> policy MyPolicy set packet-siaddr=192.168.1.5 nrcmd> policy MyPolicy set packet-file-name=mybootfile.bin nrcmd> policy MyPolicy set packet-server-name=<your-sname> nrcmd> policy MyPolicy set bootp-reply-options=packet-siaddr, packet-file-name,domain-name,domain-name-servers
Step 2 Set the correct option values.
The setOption method requires spaces (not equal signs) before values.
nrcmd> policy MyPolicy setOption <your-options> <option-value>Enable BOOTP nrcmd> scope MyScope enable bootp
Step 3 Enable BOOTP.
nrcmd> scope MyScope enable bootp
Step 4 Enable dynamic BOOTP.
nrcmd> scope MyScope enable dynamic-bootp
Multimedia Cable Network Systems (MCNS) is a standard for cable modems that is part of the Data Over Cable System Interface Specifications (DOCSIS) effort. MCNS requires that the cable modem use DHCP to get its start-up parameters, and then download more detailed configuration through TFTP. The DHCP parameters must include the address of the TFTP server, among other information.
To configure the Network Registrar policies to support MCNS cable modems, set the packet-siaddr property, the packet-file-name property, the Security Server option (if any), and the required options (if any). Set the packet-siaddr to the IP address of the TFTP server and the packet-file-name to the boot file that the cable-modem will download from the TFTP server. The Security Server is an optional part of the MCNS specification.
Step 1 Configure the boot file.
nrcmd> policy MyPolicy set packet-file-name=<myfile>
Step 2 Configure the TFTP server's IP address.
In this example, the TFTP server's IP address is 204.253.96.115.
nrcmd> policy MyPolicy set packet-siaddr=204.253.96.115
Step 3 Configure the Security Server option.
In this example, the Security Server has the same IP address as the TFTP server.
nrcmd> policy MyPolicy setOption mcns-security-server 204.253.96.115
Step 4 Require that the Security Server, packet boot-file, and packet siaddr options be returned, even if the cable modem did not request them.
nrcmd> policy MyPolicy set dhcp-reply-options=mcns-security-server, packet-file-name,packet-siaddr
After the Network Registrar DHCP server has given a client a lease, you can have that lease-state data written back to your LDAP server. Thus, you can store information such as the client's host name, the machine's MAC address, the state of the lease, and when the lease expires. Since a copy of this information is in a central place (your LDAP server), you can run queries to monitor your IP address usage or the state of your leases.
You can configure multiple independent LDAP servers that the Network Registrar DHCP server can use in preference order (for failover protection), or in round-robin fashion (for load balancing).
LDAP directory servers provide a way to name, manage, and access collections of attribute-value pairs. LDAP servers consist of entries that hold information about some thing or concept, such as a person or organization. Every entry in an LDAP server belongs to one or more object classes. The object class defines the attributes and their associated valid values. For example, the person object class might have an attribute to hold a person's Social Security number, which would be single-valued; or an attribute to hold a telephone number, which would ignore spaces and dashes. The schema defines an entry's valid attributes and their values. You can turn off schema checking if you want to use the attributes to hold other values. Or, you can change the schema by adding new object classes to an entry.
To use your LDAP server for DHCP queries, enter the MAC addresses of all your clients. You can optionally enter any other information on a per-client basis, such as a unique host name or if you are using client-class---exceptions to the client's client-class definition.
Any of the DHCP client-entry attributes that you can configure through Network Registrar can be stored in the LDAP server. All these attributes are of the type string.
For more information about these attributes, see the Network Registrar CLI Reference Guide.
You can enter information into your LDAP server in any number of ways, because Network Registrar is not dependent on any specific LDAP object classes or schema:
The following example (Table 4-1) assumes you have entered the DHCP client data into the standard LDAP organizational person object class attributes.
| LDAP Attribute | DHCP Client Entry |
|---|---|
MAC address | |
To enable the DHCP server to query your LDAP server for client data, perform the following steps. Like local client-entries, LDAP client-entries are keyed by the client's MAC address. For more information about the MAC address format, see the Network Registrar CLI Reference Guide.
Step 1 Tell DHCP about your LDAP server.
Supply a host name. The following example creates the LDAP server object myserver with a host name of myserver.american.com.
nrcmd> ldap myserver create myserver.american.com
Step 2 Configure the credentials to use when connecting to the LDAP server.
The following example sets the admin to be joe and his password to be access. Use the distinguished name for the user.
nrcmd> ldap myserver set username="cn=joe, o=Sample Corp, c=US" nrcmd> ldap myserver set password=access
Step 3 Set the search-path.
This is a point in the directory from which to start searches. The following example sets the base of the search to be the organization, Sample Corp., and the country, US.
nrcmd> ldap myserver set search-path="o=Sample Corp, c=US"
Step 4 Set the search-filter to be the attribute for which DHCP will substitute the clients' MAC addresses.
In this example the attribute is the common name (cn).
nrcmd> ldap myserver set search-filter=(cn=%s)
Step 5 Configure a query-dictionary, which contains all the LDAP-to-DHCP mappings.
Use the setEntry command to set these mappings.
(a) Search for the surname (sn) to use for the DHCP host name.
nrcmd> ldap myserver setEntry query-dictionary
sn=host-name
(b) Search for the first name (givenname) to use for the specific client-class name.
nrcmd> ldap myserver setEntry query-dictionary givenname=client-class-name
(c) Search for the localityname to use for the domain name.
nrcmd> ldap myserver setEntry query-dictionary localityname=domain-name
Step 6 Enable queries for the LDAP server.
The following example enables queries for myserver.
nrcmd> ldap myserver enable can-query
Step 7 Enable client-class processing for the DHCP server.
nrcmd> dhcp enable client-class
Step 8 Enable the DHCP server to use LDAP for client-entry queries.
nrcmd> dhcp enable use-ldap-client-data
Step 9 Save and reload the DHCP server.
nrcmd> server dhcp reload
For more information about the ldap command and client-class properties, see the Network Registrar CLI Reference Guide.
You can configure the DHCP LDAP service to copy lease-state data to existing attributes in the LDAP server. The service converts the lease-state data to string form, and uses an update dictionary to map the LDAP attributes to the DHCP data values.
Each time the state of a lease changes, the DHCP server makes a copy of the data and then transfers it to the LDAP server that you have configured to store lease-state data.
You can store any of the following attributes about the lease's state information in your LDAP server:
Not every lease has all of these attributes. The client-mac-addr and client-id are not present if a lease has been released by its client, or forced available through Network Registrar.
There are three steps to configuring lease-state updates:
Step 1 Choose the lease-state update scheme.
Step 2 Add entries to the directory or modify existing entries to store the lease state information. You may need to extend entries through the addition of attributes or custom object classes.
Step 3 Configure Network Registrar to perform the updates.
Given the flexibility of directories, there are many different ways in which you could choose to store a copy of lease-state attributes in a directory. For example, you could choose to store the lease-state data as part of an existing entry, or you could store the lease-state data independently.
The advantage to this method is that lease data is stored directly with other associated client information. The disadvantage is that there are scenarios, albeit unlikely, related to client-class and reservations that could result in stale data being in the directory for a short period of time when a client is moved off a lease by the server.
Also, this method requires two LDAP interactions in order to write the lease information. When updating lease-state information, the DHCP LDAP service contacts the directory twice because when updating an entry it is not enough just to know how to find the entry. You must specifically know the entry's distinguished name.
The DHCP LDAP service first finds the appropriate entry in the directory by using one the lease-state attributes that you chose (preferably the MAC address) as the search criteria. This is necessary to do since none of the lease-state attributes is part of the distinguished name of the entry. When the DHCP LDAP service locates the entry, the distinguished name is returned. Then the DHCP LDAP service updates that same entry with the appropriate information. For an example of using this method, see the "Configuring LDAP State Updates" section later in this chapter.
To update the lease-state information, the DHCP LDAP service contacts the directory service once. When performing the update, DHCP LDAP service uses the IP address to construct the distinguished name.
There are two ways you might use the LDAP update feature:
When using Network Registrar, you should be aware of the following:
The following example shows what to do when the LDAP object's dn (distinguished name) cannot be constructed from data that is available in the lease state. The DHCP server creates an LDAP query based on the update-search-xxx information, locates the LDAP object, and uses its distinguished name to issue an LDAP update.
The example shown in Table 4-2 assumes you are using the standard LDAP organizational person object class attributes to hold lease update data.
| LDAP Attribute | DHCP Lease Entry |
|---|---|
address (IP address) | |
state (lease state) |
Step 1 Tell DHCP about your LDAP server.
You must supply the server's host name. The following example creates the LDAP server object myserver with a host name of myserver.american.com.
nrcmd> ldap myserver create myserver.american.com
Step 2 Configure the credentials to use when connecting to the LDAP server.
The following example sets the admin to be joe and his password to be access. Use the distinguished name for the user.
nrcmd> ldap myserver set username="cn=joe, o=Sample Corporation, c=US" nrcmd> ldap myserver set password=access
Step 3 Configure the update-search-path, which is the starting point in the directory for the objects that the DHCP server will update.
The following example sets the search path to begin at the organizational unit (ou) IT, the organization Sample Corporation, and country US.
nrcmd> ldap myserver set update-search-path="ou=IT, o=Sample Corp, c=US"
Step 4 Set the ID of the attribute you want to use to search for the LDAP object that will be updated.
The following example sets the search attribute to be the client's MAC address.
nrcmd> ldap myserver set update-search-attribute=client-mac-addr
Step 5 Configure a filter expression into which the update-search-attribute should be formatted.
This expression must contain a %s, which indicates where the search-attribute's data should be substituted.
nrcmd> ldap myserver set update-search-filter=(cn=%s)
Step 6 Configure an update-dictionary, which allows you to identify the LDAP attributes that you want set with the values of the corresponding lease-state attributes.
The following example specifies the LDAP uid should be updated to contain the IP address, and the attribute carlicense should be updated to contain the DHCP lease-state information.
nrcmd> ldap myserver setEntry update-dictionary
uid=address carlicense=state
Step 7 Enable queries for the LDAP server.
The following example enables queries for myserver.
nrcmd> ldap myserver enable can-query
Step 8 Enable updates for the new LDAP server.
nrcmd> ldap myserver enable can-update
Step 9 Save and reload the DHCP server.
nrcmd> server dhcp reload
A scope is an administrative grouping of TCP/IP addresses. You create one or more scopes for each subnet on the network to pool addresses for that subnet. The following sections discuss defining and using scopes.
Each scope needs to have the following information:
You can configure multiple scopes (with disjoint ranges of IP addresses) that have the same network number and subnet mask. The DHCP server pools together the available leases from all of the scopes on the same subnet together and offers them, in a round-robin fashion, to any client that requests a lease (that is, for which there is no reservation or previous lease information available).
You might want to configure the addresses for a single subnet into multiple scopes to increase the speed of the GUI update for the Leases tab. Another reason might be to organize the addresses in a more natural way for administration---although remember that unless the client has a reservation or is a member of a client-class there is no way to control from which scope a client will obtain a lease.
Because each scope can have a separate reservation list, you might want to organize the leases in multiple scopes on the same subnet. You could put all the dynamic leases in one scope, with a policy with one set of options and lease times, and all the reservations in another scope, with a different policy of options or lease times.
You can also have multiple scopes for different subnets and some of the scopes may not be locally connected to your computer. If this is the case, you should ensure that the router (with BOOTP Relay Support) is configured with the appropriate helper address.
When multiple scopes are available on a particular subnet (through the use of a secondary subnet), the DHCP server searches through all of them looking for a scope that meets the needs and requirements of an incoming DHCP client request. For instance, if a subnet has three scopes, only one of which supports dynamic BOOTP, any BOOTP request for which there is not a reservation in another scope is automatically satisfied from the scope that supports dynamic BOOTP.
In addition, you can configure a scope to disallow DHCP requests (the default is to allow DHCP requests). By using these capabilities together, you can easily configure the addresses on a subnet so that all of the DHCP requests are satisfied from one scope (and address range), all of the reserved BOOTP requests come from a second scope, and all of the dynamic BOOTP requests come from a third scope. This allows you to support dynamic BOOTP while minimizing the impact on the address pools that support DHCP clients.
Step 1 Use the scope create command to create a scope and supply the network number for the subnet and the subnet mask.
nrcmd> scope testScope create 192.168.1.0 255.255.255.0
Step 2 Use the scope set command to specify the policy for the scope.
nrcmd> scope testScope set policy=internal
Step 3 Use the scope command addRange method to specify the range of IP addresses for the scope.
nrcmd> scope testScope addRange 192.168.1.10 192.168.1.100
You can use the scope command to change scope features or properties.
Use the scope enable command to enable a scope feature. For example to enable the ping-clients feature, type:
nrcmd> scope testScope enable ping-clients
Although removing a scope from the configuration of a DHCP server is easy to do, you should be very careful whenever you perform this operation. The DHCP protocol, as defined by the IETF, provides a lease to a client for a particular IP address for a specific amount of time (defined by the administrator of the server). Until that time has elapsed, the client is free to use the IP address it has been leased. There is no defined way for the server to revoke a lease, and to cause a client to stop using an IP address. As a result, while you can easily remove a scope from a DHCP server, the clients who have obtained leases on IP addresses from this scope will continue to use them until the expiration of the lease. This is true even if the server does not respond to their attempts to renew the lease (as is the case if the scope has been removed from the server).
If the addresses from the scope that you have removed are not configured into another DHCP server or reused in any way, then this is not a problem. If, however, the addresses contained in this scope are placed into another DHCP server before the expiration of the last lease, the same IP address might be in use by two different clients. This situation can cause serious errors in operation.
In other words, do not simply remove a scope from one DHCP server and add the addresses into another scope in a different DHCP server. Doing so compromises the integrity of your network. There are several ways to accomplish the operation of removing a scope from a DHCP server.
If you do not plan to reuse the addresses from the scope, you can remove the scope from the DHCP server.
Use the scope delete command to delete a scope.
nrcmd> scope testScope delete
If you do want to reuse the addresses, you have two options:
Use the lease list command to list the leases in a cluster
nrcmd> lease list
The reason you would choose to deactivate a lease is to move a client off of a lease. If the lease is available, deactivating the lease prevents Network Registrar from giving the lease to a client. If the lease is leased (held by a client), deactivating the lease prevents the client from renewing the lease, and Network Registrar from giving it to another client. You can only deactivate a lease if the server is running. Network Registrar deactivates the lease immediately; you do not need to reload the DHCP server.
Use the lease deactivate command to prevent the lease from being given out or renewed.
nrcmd> lease 192.168.1.20 deactivate
To deactivate all the leases in a single scope, disable BOOTP and DHCP. For more information see the "Deactivating a Scope" section later in this chapter.
The force-available property allows you to make a lease currently held by a host available. If the lease is currently held, you should request that the user release the lease, or do so yourself, before selecting this option. You do not need to reload the DHCP server to make the change take effect.
Use the lease force-available command to make the currently held lease available.
nrcmd> lease 192.168.1.21 force-available
Use the lease list command to show the state of all the leases.
nrcmd> lease list
To ensure that a client always gets the same lease, reserve the lease. You reserve a lease by pairing an IP address with the host's MAC address. You can choose any valid IP address that is within your network number. The IP address does not have to be one that is listed in the scope's range of addresses. In fact, you can use the scope's range of IP numbers for dynamic leases, and use other addresses for reserved leases.
The leases should have the same network number and subnet mask as the scope. Network Registrar displays the current network number and subnet mask in noneditable fields above the lease reservation grid.
You must reserve leases for DHCP clients whose addresses must remain constant.
 | Caution If multiple DHCP servers are distributing addresses in the same subnet, the client reservations on each DHCP server should be identical. Otherwise, the DHCP reserved client may receive multiple offers of IP addresses, each from a different server. |
Use the scope command addReservation method to reserve a reservation. Specify the lease's IP address and the client's MAC address.
nrcmd> scope testScope addReservation 192.168.1.10 1,6,00:a0:24:2e:9c:20
Although you can remove reservations at anytime, if the lease is still held, the client will continue to use the lease until the lease expires. If you reserve this lease for someone else, Network Registrar displays a message to that effect when you start the DHCP server.
Use the scope command removeReservation method to delete a reservation.
nrcmd> scope testScope removeReservation 192.168.1.10 1,6,00:a0:24:2e:9c:20
You can use the scope selection-tags property to associate existing selection tags with this scope. For more information, see the "Defining Scope Selection Tags" section earlier in this chapter.
Use the scope set command to associate a selection tag with this scope.
nrcmd> scope testScope set selection-tags=internal
You can use the scope command to set the following advanced scope options.
The DHCP server makes use of the ICMP echo request and echo reply packets to determine whether a particular IP address is currently in use. If a computer responds to the ping, the DHCP server marks that address as unavailable and offers a different IP address to the client.
Use the scope enable command to enable the ping-clients feature.
nrcmd> scope testScope enable ping-clients
Network Registrar supports multiple logical subnets on the same physical network segment, which are called secondary subnets. If you have several logical subnets on the same physical network, for example, 192.168.1 and 192.168.46, you might want to configure DHCP so that it will offer addresses from both pools. By pooling addresses this way, you can combine two Class C networks or a Class B and Class C network.
To join two logical subnets, create two scopes, and elect one to be primary and the other secondary. After you have configured the secondary subnet, any client on this physical network will obtain a lease from one or the other scope, on a round-robin basis (as long as the client does not have a reservation or previous lease information).
Step 1 Use the scope set command as follows:
nrcmd> scope testScope set primary-scope=Example
Step 2 Use the server reload command to reload the server.
nrcmd> server DHCP reload
The nrcmd command automatically fills in the primary scopes's address and netmask.
BOOTstrap Protocol (BOOTP) was originally created for loading diskless computers. This protocol was later used to allow a host to obtain all the required TCP/IP information to be able to use the Internet. BOOTP functions by allowing a host to broadcast a request onto the network, and obtains information required from a BOOTP server. The BOOTP server is a computer that listens for incoming BOOTP requests and generates responses from a configuration database for the BOOTP clients on that network. BOOTP differs from DHCP in that it has no concept of lease or lease expiration. All IP addresses allocated by a BOOTP server are permanent.
You can configure Network Registrar to act like a BOOTP server. In addition, although BOOTP normally requires static address assignments, you can choose to either reserve IP addresses (and therefore use static assignments) or have IP addresses dynamically allocated. For more information about configuring BOOTP, see the "Configuring BOOTP" section earlier in this chapter.
Use the scope enable command to enable the bootp feature.
nrcmd> scope testScope enable bootp
You can disable DHCP for this scope if you want to use the scope only for BOOTP.
Step 1 Use the scope disable command to disable the bootp feature.
nrcmd> scope testScope disable bootp
Step 2 Use the scope enable command to disable the dhcp feature.
nrcmd> scope testScope enable dhcp
To deactivate all the leases in a scope, disable BOOTP and disable DHCP.
Step 1 Use the scope disable command to disable the bootp feature.
nrcmd> scope testScope disable bootp
Step 2 Use the scope disable command to disable the dhcp feature.
nrcmd> scope testScope disable dhcp
Network Registrar's dynamic DNS update allows the DHCP server to tell the DNS server or servers when a name-to-address association has been created or changed. When a host obtains a lease for an address, Network Registrar tells DNS to add it to its database. When the lease expires, or when the client gives up an address, Network Registrar tells DNS to remove the association. In normal operation you, as administrator, do not have to reconfigure DNS, no matter how frequently the clients' addresses change through the use of DHCP. Network Registrar uses the host name that the client computer provides. If you choose, Network Registrar can automatically create names for clients who have not provided one.
The Network Registrar dynamic DNS update is used for individual hosts instead of the DNS servers themselves. DNS servers' addresses are entered into the DHCP client information database and should therefore only be changed infrequently. DNS servers' addresses are often known to one another for backup or performance reasons, so changing their addresses in a mixed environment is not very useful. For security, the DHCP servers must know the addresses of the DNS servers that they update, and the DNS servers must know the addresses of the DHCP servers from which they are authorized to accept updates.
The Network Registrar DHCP server stores all pending DNS update information on disk. If DHCP cannot communicate with a particular DNS server, it periodically tests if communications have been reestablished, and submits all pending updates when they have been updated. This test typically occurs once every 40 seconds until communication with DNS is reestablished.
You can use the scope command to enable Dynamic DNS for the scope.
Step 1 Use the scope set command to set the values for the zone name.
This is the name of the zone to which a DHCP client's host name should be added. For example, if you want your DNS name to be beth.QuickExample.com, specify the zone QuickExample.com.
nrcmd> scope testScope set dns-zone-name=QuickExample.com
Step 2 Use the scope set command to set DNS server's IP address.
You should specify the IP address of the primary server on which both the forward and reverse zones reside. Both zones must be primary servers, and must be on a server that supports the DDNS protocol.
nrcmd> scope testScope set dns-server-addr=192.168.1.1
Step 3 Use the scope set command to set DNS reverse zone's name.
This is the name of the zone to be updated with PTR and TXT records.
nrcmd> scope testScope set
dns-reverse-zone-name=1.168.192.in-addr.arpa
Step 4 Use the scope set command to set DNS reverse zone's IP address.
nrcmd> scope testScope set
dns-rev-server-addr=192.168.1.14
Step 5 Use the scope enable command to enable dynamic updates for this scope.
nrcmd> scope testScope enable dynamic-dns
Step 6 Use the server command to reload the server.
nrcmd> server DHCP reload
Step 1 Use the zone enable command to enable dynamic DNS updates from host names.
nrcmd> zone example.com enable dynamic
Step 2 Use the zone set command to specify the name of the server.
nrcmd> zone example.com set dynupdate-set=192.168.1.10
Repeat this procedure for both the primary and reverse DNS zones; for example, the primary zone example.com and the reverse zone 1.168.192.in-addr.arpa.
After you have configured the DNS and DHCP servers, you must reload them to write the configuration information to the Network Registrar database.
Use the server command to reload the server.
nrcmd> server DNS reload
Repeat for the DHCP server.
Posted: Thu Jul 13 11:33:53 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.