|
|
This chapter describes how to configure Network Registrar using the nrcmd program commands.
The beginning of the chapter describes the following procedures:
The remainder of this chapter describes the nrcmd commands in more detail. For more information about each command, see the "Using Nrcmd Commands" chapter.
You can use the nrcmd program in batch mode by executing scripts that use the commands, or by using the interactive mode in which you enter commands at the nrcmd program prompt.
The command syntax is as follows:
nrcmd general-options command specific-options
The general options are:
-C clustername -N username -P password
These general options are not required. If you supply them, you must proceed them with -C, -N, or -P. If you do not supply them, Network Registrar gets them from the registry (on Windows NT), or environment variables (on Solaris and Windows NT). If Network Registrar cannot find values for these parameters, it prompts you for them.
The Windows NT registry and Solaris or Windows NT environment variables are AIC_NAME for the name, AIC_PASSWORD for the password, and AIC_CLUSTER for the cluster name. The Windows NT registry path is Software\American Internet\Registrar\2.0 and the registry hive is HKEY_CURRENT_USER.
To execute the command line interface in interactive mode, type:
nrcmd [-C cluster] [-N user] [-P password]
Typing this command displays the interactive prompt nrcmd> to which you type:
nrcmd> command [optional parameters]
To terminate an interactive session, type exit.
To view the online help, type help.
The nrcmd commands in this chapter all follow the same command syntax. Commands specify a class of object, which you can create, delete, or list. Each of these objects in turn has properties, which you can set or get, and features, which you can enable, disable, or test. These objects may also have methods, which are specific to the type of object, that let you add or remove groups of properties.
When you use the nrcmd commands to configure Network Registrar, you manipulate the following:
How you specify a series of arguments depends on the type of command you are using. The following sections describe the differences when using the create, set, and enable commands.
When you use the create command and there are required arguments, you must supply them. You can also supply additional arguments. You must supply the required arguments in the specified order; however, you can specify the optional arguments in any order with the syntax prop=value.
For example, the syntax for creating a scope is scope name create addr mask [prop=value], which means that you must supply an IP address and mask when you create a scope, and you can optionally specify other properties of the scope.
The following example creates the scope testScope with the IP address of 128.103.1.1 and a mask of 255.255.255.0:
nrcmd> scope testScope create 128.103.1.1 255.255.255.0
For example, if you want to create a scope and also specify the name of the DNS zone to which a DHCP client's host name should be added, enter:
nrcmd> scope testScope create 128.103.1.1 255.255.255.0 dns-zone-name=QuickExample.com
After the create command creates and assigns all specified parameters to the object, it checks that all the required properties have values (either defaults or user-specified). If you neglect to supply the required arguments, Network Registrar reports an error.
You use the set command to set the value of a property. If you want to set a list of objects, such as DNS servers, or IP addresses, you can separate them with commas. You can also use the set command to set several properties on a single line. You specify the property and its value followed by a space and the next property and value pair.
For example, to specify the name of the DNS zone to which a DHCP client's host name should be added, type:
nrcmd> scope testScope set dns-zone-name=QuickExample.com
For example, to specify the list of IP addresses that you will allow to perform zone transfers, type:
nrcmd> zone QuickExample.com set auth-servers=196.68.1.10,196.68.1.20
For example, to set the client's client-class and domain-name, type:
nrcmd> client 1,6,02:02:02:02:02:02 setclient-class=internal domain-name=QuickExample.com
You use the enable command to enable a feature. After you enable a feature you often need to set its associated properties.
For example, to enable increment transfer processing for the DNS server, type:
nrcmd> dns enable ixfr-enable
To change the incremental transfer expiration interval, type:
nrcmd> dns set ixfr-expire-interval=10d
The CLI waits for one of the following events before saving your changes to the database:
Programs that store information about the domain name space are called name servers. Name servers usually have complete information about some part of the domain name space, called the zone.
You need to configure three different types of primary name servers: a primary zone name server, a reverse zone name server, and a loopback name server.
The procedure is the same for all primary name servers; but they differ in the zone name. For example, if your primary zone name server is example.com with the address of 192.168.1.1, then your reverse zone is 1.168.192.in-addr.arpa, and your loopback zone is 0.0.127.in-addr.arpa.
Step 1 Use the zone command create to create a primary zone.
The following example adds the zone QuickExample.com, specifying that it is a primary zone and the name server is nameserver and the hostmaster is hostmaster:
nrcmd> zone create QuickExample.com primary nameserver hostmaster
Step 2 Use the zone command set to set the values of the zone.
You can accept the defaults or set the remaining values: expiration time, minimum TTL, refresh time, retry time, and serial number.
nrcmd> zone QuickExample.com set expire=604800 nrcmd> zone QuickExample.com set minttl=86400 nrcmd> zone QuickExample.com set refresh=10800 nrcmd> zone QuickExample.com set retry=3600 nrcmd> zone QuickExample.com set serial=121297
Step 3 Use the zone command addRR to add the Address (A) resource record.
Although the zone command automatically creates the name server (NS) and start of authority (SOA) record for you, you need to use the addRR command to create an A record for the name server named in the ns field.
nrcmd> zone QuickExample.com addRR nameserver A 192.168.1.1
If you specify the fully qualified domain name (FQDN), you need to end the name with a period, for example, QuickExample.com.
Step 4 Use the zone command addHost to add hosts.
The following example adds the host bethpc with an IP address of 192.168.1.68:
nrcmd> zone QuickExample.com addHost bethpc 192.168.1.68
For more information about the other properties that you can configure with the zone command, see the "Zone" section in the "Using Nrcmd Commands" chapter.
Use the zone command create to create a primary zone by importing an existing file that is in BIND format. The following example adds the zone QuickExample.com, specifying that it is a primary zone and to import the BIND file, hosts.local:
nrcmd> zone create QuickExample.com primary file=hosts.local
To import your entire named.boot file, use the import command. For more information about this command, see the "Import" section in the "Using Nrcmd Commands" chapter.
A secondary zone can assume some of your primary zone's tasks by answering queries about the domain because it receives zone transfers from your primary server. The secondary zone also can handle queries about its own domain.
Step 1 Use the zone command create to create a secondary zone.
The following example adds the zone Example2.com whose address is 192.168.1.5:
nrcmd> zone create Example2.com secondary 192.168.1.5
Step 2 Optionally, use the zone command enable to restrict zone transfers for this particular zone.
nrcmd> zone Example2.com enable restrict-xfer
Step 3 Optionally, use the zone command set to indicate which servers are allowed to request a zone transfer from this secondary server.
nrcmd> zone Example2.com set restricted-set=192.168.1.1,192.168.1.20
Use the zone command addRR to add the NS record with the FQDN. The following example updates the american.com zone with the name of the zone's name server record, ns4.american.com:
nrcmd> zone american.com addRR american.com. ns ns4.american.com.
Use the server command to reload the servers:
nrcmd> server DNS reload
To configure your DHCP server, Network Registrar needs the following:
Step 1 Use the scope command create to add scopes.
The following example adds the scope testScope, with the network address of 192.168.1.0, and a netmask of 255.255.255.0:
nrcmd> scope testScope create 192.168.1.0 255.255.255.0
Step 2 Use the scope command addRange to add a range of addresses. The following example adds the addresses 192.168.1.9 - 192.168.1.100:
nrcmd> scope testScope addRange 192.168.1.9 192.168.1.100
You can change the netmask on an existing scope without modifying anything else.
Policies allow you to group lease times and other configuration parameters that a DHCP server then assigns to a client. These parameters are called DHCP options.
Step 1 Use the policy command create to create a policy. The following example creates the policy 168.1-net:
nrcmd> policy create 168.1-net
Step 2 Use the policy command setOption to add options to your policy.
The following example adds the domain-name option with the value of example.com:
nrcmd> policy 168.1-net setOption domain-name=example.com.
Step 3 Use the policy command setLeaseTime to specify the lease time.
The following example sets the lease time to one hour. You should specify the time in seconds:
nrcmd> policy 168.1-net setLeaseTime 3600
Step 4 Use the scope command policy to associate this policy with a specific scope.
The following example associates the 168.1-net policy with the testScope:
nrcmd> scope testScope set policy=168.1-net
For more information about the policy command, see the "Policy" section in the "Using Nrcmd Commands" chapter. For more information about the scope command, see the "Scope" section in the "Using Nrcmd Commands" chapter.
Use the scope command addReservation to add reservations to the scope. The following example adds the reserved lease 192.168.1.10 for the client with the MAC address of 1,6,00:a0:24:2e:9c:20:
nrcmd> scope testScope addReservation 192.168.1.10 1,6,00:a0:24:2e:9c:20
For an explanation of how to specify a MAC address, see the "Client" section in the "Using Nrcmd Commands" chapter.
Using DHCP and dynamic DNS update, a host is automatically configured for network access whenever it attaches to the IP network. The host can be located and accessed using its permanent, unique DNS host name. Mobile hosts, for example, can move freely around on a network without end user or administrator intervention.
Step 1 Use the scope command set 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, you need to specify the QuickExample.com zone.
nrcmd> scope testScope set dns-zone-name=QuickExample.com
Step 2 Use the scope command set 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. They must be on the same server, they must be both primary servers, and they must be on a server that supports the Dynamic Domain Name Server (DDNS) protocol.
nrcmd> scope testScope set dns-server-addr=192.168.1.1
Step 3 Use the scope command set 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 command enable to enable dynamic updates for this scope.
nrcmd> scope testScope enable dynamic-dns
Step 5 Use the server command reload to reload the server.
To configure dynamic DNS update, you need to configure a primary DNS zone.
Step 1 Use the zone command set to specify the DHCP servers from which this DNS domain accepts updates.
The following example specifies servers 192.168.1.1 and 127.0.0.1:
nrcmd> zone QuickExample.com set dynupdate-set=192.168.1.1,127.0.0.1
Step 2 Use the zone command enable to enable dynamic DNS updates.
The following example enables dynamic DNS updates for the QuickExample zone:
nrcmd> zone QuickExample.com enable dynamic
Step 3 Use the server command reload to reload the server.
nrcmd> server DNS reload
You can 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, the most common uses are for:
Scope selection tags are names that you can use to associate a scope with a given Class of Service. You can order your network by quality of service, such as good, better, best, and assign these selection tags to different scopes. You can then sort your user community into groups that can access either the good, the better, or the best scopes depending on their client-class affiliation.
Step 1 Use the scope-selection-tag command create to create a selection tag.
The following example creates the selection tags good, better, best:
nrcmd> scope-selection-tag create good nrcmd> scope-selection-tag create better nrcmd> scope-selection-tag create best
Step 2 Use the scope command set to add the selection tag to the scope, testScope.
nrcmd> scope testScope set selection-tags best
Step 3 Repeat Steps 1 and 2 for the other selection tags you want to create and add.
The client-class category is a method of grouping a set of selection tags that can be applied to a group or class of clients. For example, if your user community was a university, you might want to divide it by students and faculty, and then associate these classes with scopes that provide different Classes of Service.
Step 1 Use the client-class command create to create a client-class.
The following example creates the client-class Students:
nrcmd> client-class create Students
Step 2 Use the client-class command set to add the host name.
The following example adds the host name string @use-macaddress, which causes the server synthesize a host name for the client that is derived from its MAC address:
nrcmd> client-class Students set host-name=@use-macaddress
Step 3 Use the client-class command set to assign the policy to a class of clients.
The following example assigns the policy 168.1-net:
nrcmd> client-class Students set policy-name=168.1-net
Step 4 Use the client-class command set to add the option domain name.
The following example adds the QuickExample.com domain:
nrcmd> client-class Students set domain-name=QuickExample.com
Step 5 Use the client-class command create to add an action.
Specify an action only if you want to create a special class: one that excludes clients or one that offers a lease only the first time the client requests one. For example, you could create a client-class LegacyHardware, such as old BOOTP devices. Each time such a device requested an IP address, the DHCP server would deny access.
nrcmd> client-class create LegacyHardware nrcmd> client-class LegacyHardware set action=exclude
Step 6 Use the client-class command set to set the selection criteria to a defined scope tag.
The following example sets the selection criteria to the tag good. Specifying the good tag means that all clients who are members of the Students client-class, will receive addresses from the scopes associated with the good selection tag.
nrcmd> client-class Students set selection-criteria=good
Step 7 Use the client-class command set to set the exclusion criteria.
The following example sets the exclusion criteria to best. Specifying the best exclusion criteria means that all the clients, who are members of the Students client-class, will never receive addresses from scopes associated with the best property.
nrcmd> client-class Students set selection-criteria-excluded=best
Step 8 Use the client-class command set to add a user-defined string, which you can use to add descriptive information.
nrcmd> client-class Students setuser-defined="student ID number"
Step 9 Repeat Steps 1 through 8 for the other client-classes you want to create
If you plan to assign your clients to client-classes, you only need to specify the client's MAC address. You can have the client-class membership supply the other values. You can, however, specify different values for the client, and Network Registrar will use those in lieu of the client-class values.
Step 1 Use the client command create to create the client by specifying the client's MAC address.
The following example creates the client with the MAC address of 1,6,00:a0:24:2e:9c:20:
nrcmd> client create 1,6,00:a0:24:2e:9c:20
Step 2 Use the client command set to add the host name.
The following example adds the host name @use-macaddress, which causes the DHCP server to synthesize a host name from the client's MAC address:
nrcmd> client 1,6,00:a0:24:2e:9c:20 set host-name=@use-macaddress
Step 1 Use the client command set to set a specific policy for a client.
The following example adds the policy 168.1-net:
nrcmd> client 1,6,00:a0:24:2e:9c:20 set policy-name=168.1-net
Step 2 Use the client command set to specify a client-class for a client.
The following example adds the Students client-class:
nrcmd> client 1,6,00:a0:24:2e:9c:20 set client-class-name=Students
Step 3 Use the client command set to add the selection criteria.
nrcmd> client 1,6,00:a0:24:2e:9c:20 set selection-criteria=good
Step 4 Use the client command set to add the exclusion criteria.
nrcmd> client 1,6,00:a0:24:2e:9c:20 set selection-criteria-excluded=best
Step 5 Use the client command set to set the user-defined string.
nrcmd> client 1,6,00:a0:24:2e:9c:20 set user-defined=Eastcampus
If you want a distinct boot-file option value to be returned to a specific client, you need to create both a client entry and a policy for each custom modem. The client entry refers to the policy, and the policy defines the option, boot-file, with the bootfile name for that custom modem.
You can also have the client entry for the custom modem refer to a client-class, which might in turn refer to a different policy with the options that are common to that group of custom modems.
For example, if you have a custom modem with MAC address 1,6,01:02:03:04:05:06 that should have the boot file custom-01:02:03:04:05:06, and should share the other options from the custom-modem class of clients, you would configure the following objects:
Step 1 Create the custom-modem policy to contain the common options.
nrcmd> policy create custom-modem nrcmd> policy custom-modem addOption dhcp-lease-time 720000
Step 2 Add other options as necessary.
Step 3 Create the custom modem client-class.
nrcmd> client-class create custom-modem policy-name=custom-modem
Step 4 Create the policy for the modem, and set the boot-file option.
nrcmd> policy create 01:02:03:04:05:06 nrcmd> policy 01:02:03:04:05:06 setOption boot-file custom-01:02:03:04:05:06
Step 5 Create the client entry for the modem.
nrcmd> client create 1,6,01:02:03:04:05:06 client-class-name=custom-modem policy
Before you can use client-class, you need to enable it for your DHCP server.
Use the dhcp command enable to enable client-class.
nrcmd> dhcp enable client-class
Use the server command reload to reload the servers.
nrcmd> server DNS reload nrcmd> server DHCP reload
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 need to move or decommission a BOOTP client, you can reuse its lease by using the lease force-available command.
When you configure the DHCP server to return a BOOTP packet, you need to 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.
The Network Registrar 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.
You can configure both the BOOTP and DHCP response packets appropriately for your devices.
To configure a BOOTP packet, you need to do the following:
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 name. The fields have names such as packet-siaddr, packet-file-name, and packet-server-name.
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.
nrcmd> policy MyPolicy setOption=<your-options>
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.
You need to configure the Network Registrar policies to support MCNS cable modems. You do this by setting the packet-siaddr property, the packet-file-name property, the Security Server option (if any), and the required options (if any). You must 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 option is an optional part of the MCNS specification.
To configure MCNS, follow these steps:
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 option 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. 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. Because 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 object 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.
In order to use your LDAP server for DHCP queries, you need to enter the MAC addresses of all your clients. You can optionally enter any other information that you need to apply 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. Note that all these attributes are of the type string.
For more information about these attributes, see the "Client" section in the "Using Nrcmd Commands" chapter.
You can enter information into your LDAP server with the following methods, 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 assumes you have entered the DHCP client data into the standard LDAP organizational person-object class attributes.
| LDAP Attribute | DHCP Client Entry |
|---|---|
MAC address | |
client-class-name | |
domain-name | |
host-name |
To enable the DHCP server to query your LDAP server for client data you need to perform the following steps. LDAP client-entries are keyed by the client's MAC address, such as local client-entries. For more information about the MAC address format, see the "Client" section in the "Using Nrcmd Commands" chapter.
Step 1 Notify DHCP about your LDAP server.
You need to 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. You need to use the distinguished name for the user.
nrcmd> ldap myserver set username="cn=joe, o=XYZ Co, 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, XYZ Co, and the country, US:
nrcmd> ldap myserver set search-path="o=AXYZ Co, 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.
You use the setEntry command to set these mappings.
Search for the surname (sn) to use for the DHCP host name. Search for the first name (givenname) to use for the specific client-class name. Search for the localityname to use for the domain name.
nrcmd> ldap myserver setEntry query-dictionary sn=host-name nrcmd> ldap myserver setEntry query-dictionary givenname=client-class-name nrcmd> ldap myserver setEntry query-dictionary localityname=domain-name
Step 6 Enable queries for the LDAP server.
The following example enables queries for the 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
Step 10 For more information about the ldap command, see the "Ldap" section in the "Using Nrcmd Commands" chapter. For more information about client-class properties, the "Client" section in the "Using Nrcmd Commands" chapter.
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:
There are three steps to configuring lease-state updates:
1. Choose the lease-state update scheme.
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.
3. Configure Network Registrar to perform the updates.
Given the flexibility of directories, there are many different ways in which you might 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 might 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, although 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.
This method also 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 because 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. The DHCP LDAP service then 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 reasons you might use the LDAP update feature:
When using Network Registrar Software Release 2.0, you should be aware of the following:
The following example shows what you need 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 1-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 Inform 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. You need to use the distinguished name for the user:
nrcmd> ldap myserver set username="cn=joe, o= XYZ Company, 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 XYZ Company, and country US:
nrcmd> ldap myserver set update-search-path="ou=IT, o=AXYZ Company, 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 that 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
Posted: Thu Jul 13 11:14:09 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.