|
|
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.
A scope is an administrative grouping of TCP/IP addresses with associated information about those addresses. You must define a scope before DHCP clients can use the DHCP server for dynamic TCP/IP configuration.
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" section.
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.
Configure DHCP options to supply configuration parameters automatically, such as the name of your domain, the name and IP addresses of your domain name servers, 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" section.
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, on the other hand, 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 an 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 Network Registrar Concepts Guide.
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 client-class command 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 scope selection tag internal, type:
nrcmd> scope-selection-tag internal create
To debug selection tags you can use the dhcp log-settings command, 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 log-settings command, 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-06:44:40:26:f5:0f 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-06:44:40:26:F5:0F 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-06:44:40:26:f5:0f 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 physically 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>
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
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:
When you configure the DHCP server to read from LDAP, a query dictionary tells the DHCP server which LDAP attributes to query for. The DHCP server converts the resulting data into DHCP client-data attributes.
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.example.com.
nrcmd> ldap myserver create myserver.example.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=Example 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, Example Corp., and the country, US.
nrcmd> ldap myserver set search-path="o=Example 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.example.com.
nrcmd> ldap myserver create myserver.example.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=Example 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 Example Corporation, and country US.
nrcmd> ldap myserver set update-search-path="ou=IT, o=Example 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
The Network Registrar SNMP (Simple Network Management Protocol) notification support allows you to be warned of error conditions and possible problems with the Network Registrar DNS and DHCP servers, and to monitor threshold conditions that may indicate failure or impending failure conditions.
Table 4-3 describes the events that can generate notifications.
| Event | Description |
|---|---|
Address conflict with another DHCP server detected | Generates a notification when an address conflict with another DHCP server is detected. |
Configuration mismatch | Indicates a configuration mismatch between DHCP failover main and backup servers. |
DNS queue becoming too large | Generates a notification when the DHCP's DNS queue becomes too large. This is a rare internal condition. |
Duplicate IP address detected | Generates a notification whenever a duplicate IP address is detected. |
Free address threshold | Generates a notification whenever the number of free IP addresses first becomes less than or equal to the threshold after having been in a reset state. |
Other server not responding | Generates a notification when another server ((DHCP, DNS, or LDAP) is not responding. |
Other server responding | Generates a notification when another server ((DHCP, DNS, or LDAP) responds. |
Server start | Generates a notification whenever the DHCP or DNS server is started or reinitialized. |
Server stop | Generates a notification whenever the DHCP or DNS server is stopped. |
When Network Registrar generates a notification, a single copy of the notification is transmitted as an SNMP Trap PDU (Protocol Data Unit) to each recipient. The list of recipients and other notification configuration information are shared by all events (and scopes) and are read when the server is initialized.
 | Tips For more information about SNMP notification features, see the Network Registrar CLI Reference Guide or the Network Registrar Concepts Guide. |
To activate SNMP notification, you need to enable the feature and define the recipients.
Step 1 Enable SNMP notification for the particular feature you want. For example, to activate the SNMP notification when a Network Registrar server starts, type:
nrcmd> trap enable server-start
Step 2 Enable a recipient so that notification can be sent to the correct computer. For example to create a recipient netmanager, machine 192.168.1.5, the community as public, and the port 162, type:
nrcmd> trap addRecipient netmanager 192.168.1.5 public 162
To deactivate SNMP notification for a trap type, use the trap disable command.
nrcmd> trap disable server-start
To learn whether or not an SNMP notification is activated, use the trap get command.
nrcmd> trap get server-start
The free-address SNMP notification feature measures the number of free IP addresses that are available; thus you need to specify the low and high threshold properties. The DHCP server issues the free-address-low trap when the resource is equal to or less than the trap threshold value. The DHCP server automatically re-enables the trap when the resource is greater than the high value. It sends a free-address-high trap to notify the manager that the condition has cleared.
To set the free-address-low-threshold to 12 percent and the free-address-high-threshold to 22 percent, type:
nrcmd> trap set free-address-low-threshold=12% nrcmd> trap set free-address-high-threshold=22%
To remove a recipient, type:
nrcmd> trap removeRecipient netmanagers
To list all the trap recipients, type:
nrcmd> trap listRecipients
The following steps outline the process by which you configure DHCP failover. The remainder of this section describes the steps based on different site configurations.
1. Configure your DHCP server and duplicate its configuration to the backup server.
(a) Duplicate the configurations for scopes, policies, DHCP options, and IP addresses.
(b) If you have enabled Dynamic DNS updates on the main server, make sure that it is also enabled on the backup server. For more information about Dynamic DNS updates, see the "Defining Dynamic DNS Update Support" section.
(c) If you are using reservations, make sure that reservations are configured identically on each server. For more information about creating reservations, see the "Reserving a Lease" section.
(d) If you are using client-class, configure both servers with identical client-classes. For more information about client-class, see the "Enabling Client-Class" section.
Give the scopes the same set of selection tags. For more information about scope selection tags, see the "Defining Scope Selection Tags" section.
Enter the clients in both clusters, or enter them in LDAP and direct both servers to the same LDAP server. For more information about using LDAP, see the "Configuring Your LDAP Server" section.
2. Configure the server as the main server for this network and identify the backup server by specifying backup server's IP address. For instructions, see the "Configuring a Simple Site" section.
3. Configure the backup server as the backup for this network and identify the main server by specifying main server's IP address. For instructions, see the "Configuring a Simple Site" section.
4. Check that all the configuration information you have entered up to this point is identical on both servers.
5. If you are using BOOTP relays (IP helper address), configure all BOOTP relays to point to both servers. For instructions, see the "Configuring BOOTP Relays" section.
6. Reload the main server. For instructions, see the "Configuring a Simple Site" section.
7. Reload the backup server. For instructions, see the "Configuring a Simple Site" section.
In all of the following examples, the main and backup servers have already been configured identically from a scope, policy, client, and client-class standpoint, and the server-wide default capabilities are used. These examples illustrate only the failover-specific configuration commands.
In Figure 4-1 there is a main server and a single backup server.
Main Server:
Step 1 Enable failover for this DHCP server, by typing:
nrcmd> dhcp enable failover
Step 2 Specify the name of the backup server, by typing:
nrcmd> dhcp set failover-backup-server=backupserver.example.com
Step 3 Reload the server, by typing:
nrcmd> server dhcp reload
Backup Server:
Step 1 Enable failover for this DHCP server, by typing:
nrcmd> dhcp enable failover
Step 2 Specify the name of the main server, by typing:
nrcmd> dhcp set failover-main-server=mainserver.example.com
Step 3 Reload the server, by typing:
nrcmd> server dhcp reload
Instead of typing the nrcmd commands interactively, you could create a command file that you could run to configure both the main and backup servers.
dhcp enable failover dhcp set failover-main-server=mainserver.example.com dhcp set failover-backup-server=backupserver.example.com
You can change some of the system defaults, such as the number of leases that the main server should send to the backup server, or the maximum client lead time.
Main Server:
Change the poll interval---The interval that failover partners poll each other to confirm network connectivity, by typing:
nrcmd> dhcp set failover-poll-interval=10
Backup Server:
Change the poll interval---The interval that failover partners poll each other to configure network connectivity, by typing:
nrcmd> dhcp set failover-poll-interval=10
In Figure 4-2, there are several main servers and a single backup server. The main servers are Aserver and Bserver and the backup server is Cserver. The main servers have three scopes each: scope1, scope 2, and scope3 on Aserver, and scope4, scope5, and scope6 on Bserver.
Main Aserver:
Step 1 Enable failover for this DHCP server, by typing:
nrcmd> dhcp enable failover
Step 2 Specify the name of the backup server, by typing:
nrcmd> dhcp set failover-backup-server=Cserver.example.com
Main Bserver:
Step 1 Enable failover for this DHCP server, by typing:
nrcmd> dhcp enable failover
Step 2 Specify the name of the backup server, by typing:
nrcmd> dhcp set failover-backup-server=Cserver.example.com
Backup Cserver:
Because you can only specify a single default main server, if you have more than one main server, you need to list the scopes of the other servers individually. The following example enables failover for each scope on the two main servers, and designates the main server for each scope.
Step 1 Enable failover for scope1, by typing:
nrcmd> scope scope1 set failover=scope-enabled
Step 2 Specify the name of the main server, by typing:
nrcmd> dhcp set failover-main-server=Aserver.example.com
Step 3 Repeat steps 1 and 2 for scope2 and scope3.
Step 4 Enable failover for scope4, by typing:
nrcmd> scope scope4 set failover=scope-enabled
Step 5 Specify the name of the main server, by typing:
nrcmd> dhcp set failover-main-server=Bserver.example.com
Step 6 Repeat steps 4 and 5 for scope5 and scope6.
Instead of typing the nrcmd commands interactively, you could create command files that enable you to duplicate the information about servers A and B to the backup server C.
Main Aserver:
Create a file for Aserver that contains all the information about the scopes and includes the following specifications for failover.
scope scope1 set failover=scope-enabled scope scope1 set failover-main-server=Aserver.example.com scope scope1 set failover-backup-server=Cserver.example.com scope scope2 set failover=scope-enabled scope scope2 set failover-main-server=Aserver.example.com scope scope2 set failover-backup-server=Cserver.example.com scope scope3 set failover=scope-enabled scope scope3 set failover-main-server=Aserver.example.com scope scope3 set failover-backup-server=Cserver.example.com
Main Bserver:
Create a file for Bserver that contains all the information about the scopes and includes the following specifications for failover.
scope scope4 set failover=scope-enabled scope scope4 set failover-main-server=Bserver.example.com scope scope4 set failover-backup-server=Cserver.example.com scope scope5 set failover=scope-enabled scope scope5 set failover-main-server=Bserver.example.com scope scope5 set failover-backup-server=Cserver.example.com scope scope6 set failover=scope-enabled scope scope6 set failover-main-server=Bserver.example.com scope scope6 set failover-backup-server=Cserver.example.com
On Aserver run the command file, by typing:
nrcmd -b <FileA
On Bserver run the command file, by typing:
nrcmd -b <FileB
On server C run the two command files, by typing:
nrcmd -b <FileA nrcmd -b <FileB
In Figure 4-3, there are two servers that share the network and the backup responsibilities. Aserver is the main server for scopes 1-3 and the backup server for scopes 4-6, and Bserver is the main server for scopes 3-6 and the backup server for scopes 1-3.
Aserver:
Step 1 Enable failover for this scope, by typing:
nrcmd> scope scope1 set failover=scope-enabled
Step 2 Specify the name of the backup server, by typing:
nrcmd> scope scope1 set failover-backup-server=Bserver.example.com
Step 3 Repeat steps 2 and 3 for scope2 and scope3.
Step 4 Enable failover for this scope, by typing:
nrcmd> scope scope4 set failover=scope-enabled
Step 5 Specify the name of the main server, by typing:
nrcmd> scope scope4 set failover-main-server=Bserver.example.com
Step 6 Repeat steps 4 and 5 for scope5 and scope6.
Bserver:
Step 1 Enable failover for this scope, by typing:
nrcmd> scope scope1 set failover=scope-enabled
Step 2 Specify the name of the main server, by typing:
nrcmd> scope scope1 set failover-main-server=Bserver.example.com
Step 3 Repeat steps 2 and 3 for scope2 and scope3.
Step 4 Enable failover for this scope, by typing:
nrcmd> scope scope4 set failover=scope-enabled
Step 5 Specify the name of the backup server, by typing:
nrcmd> scope scope4 set failover-backup-server=Bserver.example.com
Step 6 Repeat steps 4 and 5 for scope5 and scope6.
dhcp enable failover scope scope1 set failover-main-server=Aserver.example.com scope scope1 set failover-backup-server=Bserver.example.com scope scope2 set failover-main-server=Aserver.example.com scope scope2 set failover-backup-server=Bserver.example.com scope scope3 set failover-main-server=Aserver.example.com scope scope3 set failover-backup-server=Bserver.example.com scope scope4 set failover-main-server=Bserver.example.com scope scope4 set failover-backup-server=Aserver.example.com scope scope5 set failover-main-server=Bserver.example.com scope scope5 set failover-backup-server=Aserver.example.com scope scope6 set failover-main-server=Bserver.example.com scope scope6 set failover-backup-server=Aserver.example.com
Network Registrar's failover protocol works with all existing BOOTP Relay (also called IP helper) implementations. BOOTP relay is a router capability that supports DHCP clients that are not locally connected to a DHCP server. For more information about configuring routers, see the "Configuring Routers" section.
If you are using BOOTP relay, ensure that any BOOTP relay implementations point at both the main and backup servers. If they do not and the main fails, DHCP clients will not be serviced, because the backup server cannot see the required packets.
If you cannot configure the BOOTP relay implementation to forward DHCP broadcast packets to two different DHCP servers, configure the router to forward the packets to a subnet-local broadcast address for a LAN segment, which could contain both the main and backup DHCP servers. Then ensure that both the main and backup DHCP servers are resident on the same LAN segment.
You can configure scopes to support two types of BOOTP clients: static BOOTP clients and dynamic BOOTP clients.
Static BOOTP clients are supported using DHCP reservations. When you enable failover, remember to configure both the main and the backup server with identical reservations.
Dynamic BOOTP clients are supported through the command scope enable dynamic-bootp. When you are using failover however, there are additional restrictions placed on the address usage in such scopes, because BOOTP clients are allocated IP addresses permanently and receive leases that never expire.
When a server, whose scope does not have dynamic-bootp enabled, goes to the PARTNER_DOWN state, it can allocate any available IP address from that scope, no matter whether it was initially available to the main or backup server. When dynamic-bootp is set however, the main server and backup servers can only allocate their own addresses. Consequently scopes that enable dynamic-bootp require more addresses to support failover.
When using dynamic BOOTP, do the following:
For more information about configuring dynamic BOOTP see the Network Registrar CLI Reference Guide.
There are several ways to make a simple mistake and lose the DHCP redundancy provided by the failover protocol. Make sure that you have not made one of the following mistakes:
Network Registrar will detect and log the configuration mistakes during processing, although the mistake may be detected a considerable time after the actual misconfiguration occurred.
You can only detect BOOTP configuration errors by performing live tests (akin to fire drills) in which you periodically take the main server out of service to verify that the backup server is available to DHCP clients.
After you have configured failover, the Network Registrar DHCP servers automatically perform the following actions:
1. The main server and backup server initially connect.
2. The main server supplies information about all existing leases to the backup server.
3. The backup server requests a set of available addresses from the main server to use for new clients if the main server is out of contact with the backup server.
4. The main server provides a percentage of addresses from each scope to the backup server.
5. The backup server ignores all DHCP requests (except renewals and rebindings) from DHCP clients unless it believes that the main server is down.
6. The main server updates the backup server whenever the main server performs an operation on behalf of a DHCP client.
In the event the main server fails, the backup server takes over and renews addresses of existing clients, and offers addresses to new DHCP clients.
When the main server returns from being down, it reintegrates with the backup server without administrator intervention. In this way, if the main server crashes and Network Registrar restarts the main server (or if the entire server crashes or undergoes a power loss, and then comes back) reintegration is automatic and seamless.
If the main server goes down for a long period or the backup server was allocated an unusually small percentage of leases when it first contacted the main server, the backup server may run out of addresses to offer to new clients.
In the absence of explicit actions, the backup server stops handing out addresses. This is the default behavior. The main server still renews leases to existing clients.
Should you detect this situation, you can take explicit action to allow the backup server to have access to all available address from the main server. Do the following:
After you issue this command, there is no possibility of duplicate IP address allocation.
The preferred operational mode is never to let the backup server go into PARTNER-DOWN state unless by explicit command. Allocate sufficient IP addresses to the backup server so that it can handle the arrival of new clients during periods when there is no administrative coverage. It is fairly simple to determine if the main server is down and to inform the backup server explicitly.
After you have configured failover, verify that failover is running correctly by checking the log files and running a report that displays information about the connection status of the main and backup servers.
When you check the log files for each server, note that there are two possible roles for each server with respect to every other server: it may be a main server for another server, or a backup server for another server. There is a failover object within the DHCP server for each of these roles, and the object name directly reflects its role.
When the DHCP server configures itself, it logs every network that is part of each failover object. In addition, it reports the configuration parameters (such as the failover-maximum-client-lead-time, failover-backup-percentage, failover-user-safe-period state, and so on.). For more information about these parameters, see the Network Registrar CLI Reference Guide.
You can verify your failover configuration by examining the DHCP server log files after reloading the server. You can change the amount of information reported in the log files pertaining to failover operation by doing the following:
The settings Y=1, Y=2, and log-settings log-failover-detail do not load the server or add too much information to the log files. You can leave them on for all but the most heavily loaded servers.
Both Y=3 or Y=4 debug settings slow the server considerably, and should be used only when absolutely necessary. In particular, the Y=4 setting produces a large amount of output and should be used only when you need to verify that the server is communicating at the most basic level.
Run the nrcmd server getRelatedServers command to create a report about the connection status of the main and backup servers. You can run this command from the CLI, the GUI, or the Web GUI.
The getRelatedServers command displays the following information (in Table 4-4),
| Column | Description |
|---|---|
Type | Main, Backup, DNS, or LDAP |
Name | DNS host name |
Address | IP address in dotted octet format |
Requests | Number of outstanding requests or two dashes (--) if not applicable |
Communications | OK or INTERRUPTED |
localhost State | Failover state of this server or two dashes (--) |
Partner State | Failover state of the associated failover server or two dashes (--) |
Be careful when you change the role of a failover server. Remember that all state information about IP addresses in a scope will be lost from a server if it is ever reloaded without that scope in its configuration.
This is a way to update an existing installation and increase the availability of the DHCP service it offers.
Step 1 Install Network Registrar 3.0 on the original server and ensure that it operates correctly after the installation. For information about installation, see the Network Registrar Getting Started Guide.
Step 2 Install Network Registrar 3.0 on the machine that is to be the backup server. Note the machine's DNS name. For information about installation, see the Network Registrar Getting Started Guide.
Step 3 Enable failover on the original server. Use the DNS name of recently installed backup server. For more information see "Configuring a Simple Site" section.
nrcmd>dhcp enable failovernrcmd>dhcp set failover-backup-server=backupserver.example.com
Step 4 Reload the main server. It should go into PARTNER-DOWN state and stay there, because it cannot locate the backup server (since the backup server is not yet configured). There should be no change in the operation of the main server at this point.
nrcmd>serverdhcp reload
Step 5 Duplicate the main server's configuration on the backup server, including scopes (also secondary scopes), policies, client-class. If you are using client-class, make sure that the clients are entered into each cluster or that each server can access an LDAP database with the client information.
Step 6 Enable failover on the backup server.
nrcmd>dhcp enable failovernrcmd>dhcp set failover-main-server=mainserver.example.com
Step 7 Reconfigure all the operational BOOTP relays to forward broadcast DHCP packets to both the main and the backup server.
Step 8 Reload the backup server.
nrcmd>serverdhcp reload
After you have completed these steps, the following happens:
1. The backup server detects the main server and moves into RECOVER state.
2. The backup server refreshes its stable storage with the lease information that resides on the main server, and when complete, the backup server moves into RECOVER-DONE state.
3. The main server moves into NORMAL state.
4. The backup server moves into NORMAL state.
5. The backup server uses a pool request to ask the main server for addresses to allocate if communications become interrupted.
6. After these addresses are allocated, the main server sends this information to the backup server.
If a failover server loses its stable storage (that is, its hard disk), it is possible to replace the server and have it recover its state information from its failover partner.
Step 1 Determine which server lost its stable storage.
Step 2 Use the setPartnerDown command to tell the other server that its partner is down. If you do not specify a time, Network Registrar uses the current time.
nrcmd>serverdhcp setPartnerDown other-server FEB 02 13:10 1999
Step 3 When the replacement server is operational, reinstall Network Registrar.
Step 4 Duplicate the configuration from the original server to the replacement server.
Step 5 On the replacement server, set dhcp failover-recover time to approximately when the server failed.
nrcmd> dhcp failover-recover FEB 02 13:20 1999
Step 6 Reload the replacement server.
nrcmd>serverdhcp reload
After you have completed these steps, the following happens:
1. The replacement server moves into RECOVER state.
2. The other server sends the replacement server all its information, even though it has previously sent it some of this information.
3. The replacement server moves into RECOVER-DONE state.
4. The other server moves into NORMAL state.
5. The replacement server moves into NORMAL state. The replacement server requests addresses, but few new ones are allocated, because the addresses previously allocated have been sent in step 2.
Step 1 On the backup server, remove all of the scopes that were designated as backup to the main server. Repeat for each scope that you want to remove.
nrcmd> scope name delete
Step 2 On the main server, remove the failover capability from those scopes that were main for the backup server (or disable failover server-wide if that is how it was configured).
nrcmd>scope name set failover=scope-disabled ornrcmd>dhcp disable failover
Step 3 Reload the main server.
nrcmd>serverdhcp reload
Step 4 Reload the backup server.
nrcmd>serverdhcp reload
Step 1 Duplicate the main servers scope, policy, etc., configuration on the backup server.
Step 2 Configure the main to enable failover and point to the backup.
nrcmd>dhcp enable failovernrcmd>dhcp set failover-backup-server=backupserver.example.com
Step 3 Configure the backup to enable failover for the new scopes that point to the new main.
nrcmd>dhcp enable failovernrcmd>dhcp set failover-main-server=mainupserver.example.com
Step 4 Reload both servers.
nrcmd>serverdhcp reload
Network Registrar performs the same steps as those describe in the "Making an Existing Server a Main Server and Adding a New Backup Server" section.
In the following cases, if you make any changes to your main DHCP server you need to duplicate those changes to the backup server.
Step 1 Stop the backup server.
nrcmd> server DHCP stop
Step 2 Enable import mode on the main server.
nrcmd> dhcp enable import-mode
Step 3 Reload the main server.
nrcmd> server DHCP reload
Step 4 Import the leases into the main server.
nrcmd> import leases filename
Step 5 Disable the import mode on the main server
nrcmd> dhcp disable import-mode
Step 6 Reload the main server
nrcmd> server DHCP reload
Step 7 Start the backup server.
nrcmd> server DHCP start
There are two ways that you can export lease information:
Generally, if you have enabled failover on your DHCP server you should not change the failover-maximum-client-lead-time (MCLT). If you must change the MCLT, do the following:
Step 1 Reload the backup server to ensure that all information that the backup server has to tell the main server is up-to-date on the main server. Ideally you should wait until the backup server and main server have stabilized, that is, both are in normal state, and any updates have been exchanged. At lease wait until the backup server has completed its cache update process as noted in the log file.
nrcmd> server DHCP reload
Step 2 Change the MCLT on the main server. (Remember that any MCLT configured on the backup server is ignored by the backup server, because the backup server derives its MCLT value from directly from the main server.)
nrcmd> dhcp set failover-maximum-client-lead-time=4800
Step 3 Stop the backup server.
nrcmd> server DHCP stop
Step 4 Reload the main server.
nrcmd> server DHCP reload
Step 5 Start the backup server.
nrcmd> server DHCP start
How do you know that the servers are not communicating or that one server is down? It could be a network failure or a network partition, which means that the servers can communicate, but just not with each other. In this case, however, one server could really be down. Table 4-5 describes some symptoms, causes, and solutions for failover problems.
| Symptom | Cause | Solution |
|---|---|---|
New DHCP clients fail to get IP addresses | A backup server that is in COMMUNICATIONS-INTERRUPTED state with too few IP addresses | Increase the backup percentage on the main server. |
Error messages about mismatched scopes | Mismatched scope configurations between the main and backup servers | Re-configure your servers |
Log messages about failure to communicate with partner | Partner cannot communicate with the other server |
|
Main server fails. Some clients cannot renew or rebind leases and the leases expire despite the fact that the backup server is up and possibly processing some client requests. | Neglected to configure some BOOTP relay (ip-helper) to point at both servers |
|
SNMP trap: other server not responding
| Partner cannot communicate with the other server |
|
SNMP trap: dhcp failover config mismatch | Mismatched scope configurations between the main and backup servers | Re-configure your servers |
Users complain that they are not getting access to the services they expect or that they are not able to use the system in the accustomed manner | Mismatched policies and client-classes between the main and backup servers | Reconfigure the servers to have identical policies. Possibly use LDAP for client registration if currently registering clients directly in main and backup servers. |
A scope is an administrative grouping of TCP/IP addresses. 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. Note that theses are the scope selection tags that you defined for clients and/or client-classes. 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).
To join the secondary scope to the primary scope do the following:
Step 1 Use the scope set command to set the primary scope.
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
Administrators of standard DNS have to update multiple configuration files and restart the DNS server or servers in order to change the association between a name and an address. This restricts the usefulness of DHCP, because an individual client's address may not be the same for more than a day (or even a few hours). While there is no requirement that DNS names exist for every host, there are some Internet services that will not operate correctly unless the hosts appear in DNS. One solution is to place unique names in DNS for all of the addresses allocatable by DHCP, for example, DHCP25.example.com. While this method works, you may need to have more descriptive names in DNS for your clients.
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 Nov 18 12:24:21 PST 1999
Copyright 1989-1999©Cisco Systems Inc.