Cisco CNS Network Registrar User's Guide, 5.5
Configuring DHCP Scopes and Leases
Downloads: This chapterpdf (PDF - 387.0KB) The complete bookPDF (PDF - 5.45MB) | Feedback

Configuring DHCP Scopes and Leases

Table Of Contents

Configuring DHCP Scopes and Leases

Defining and Configuring Scopes

Scopes in Network Registrar

Creating Scopes

Using Multiple Scopes

Editing a Scope

Configuring an Embedded Policy for the Scope

Making a Scope a Secondary

Enabling and Disabling BOOTP for a Scope

Disabling DHCP for a Scope

De-activating a Scope

Setting a Scope to Renew-Only

Removing a Scope

Removing a Scope if Not Re-using the Addresses

Removing a Scope if Re-using the Addresses

Configuring Leases in the Scope

Viewing Leases

Lease States

Guidelines for Lease Times

Importing and Exporting Lease Data

Pinging a Host Before Offering an Address

De-activating a Lease

Excluding a Leased Address from a Range

Reserving a Lease

Unreserving a Lease

Forcing Lease Availability

Handling Leases Marked as Unavailable

Running Address and Lease Reports

Running an Address Usage Report

Running a Lease Utilization Report

Receiving Lease Notification

Recording IP Lease History

Enabling IP History Recording

Running the IP History Query Utility

Formatting the IP History Query Output

Trimming IP History Data

Querying Leases

Lease Query Requests

Lease Query Responses

Lease Query and Reservations

Configuring DHCP Scopes and Leases

This chapter describes how to configure primary and secondary scopes for a DHCP server and how (and when) to edit and remove them, if necessary. It also describes how to activate and de-activate leases in the scope, and make lease reservations. Finally, it describes how to run reports on addresses and leases, record the IP history of leases, and support lease queries.

Configuring scopes and leases assumes that you configured a DHCP server to manage them. See "Configuring DHCP Servers." Table 8-1 lists the topics in this chapter and their associated sections.

Table 8-1 DHCP Server Scope Configuration Topics 

If you want to...
Go to the...

Learn about the concepts behind DHCP and Network Registrar's implementation

"Dynamic Host Configuration Protocol" section

Define and configure scopes for a server

"Defining and Configuring Scopes" section

Configure leases for a scope

"Configuring Leases in the Scope" section

Run reports on addresses and leases, and receive lease notification

"Running Address and Lease Reports" section

Record a history of leases

"Recording IP Lease History" section

Support querying lease information

"Querying Leases" section

Defining and Configuring Scopes

This section describes how to define and configure scopes for the DHCP server.

Scopes in Network Registrar

A scope is a range or ranges of dynamic addresses for a subnet that one or more DHCP servers manage. You must define a scope before DHCP clients can apply to one of these servers for addresses.

Tip You can include namespace names in scopes in the CLI, but not in the GUI.

In the GUI, the Scope Properties dialog box (Figure 8-1) has a number of tabs that relate to configuring a DHCP scope for a server. These tabs and where they are described in this guide are listed in Table 8-2.

Figure 8-1 DHCP Scope Properties in the GUI

Table 8-2 DHCP Server Properties in the GUI 

This tab...
Is described in...


Scope name, policy, and address ranges

"" section


Leased addresses in the scope

"Configuring Leases in the Scope" section


Reserved leases in the scope

"Reserving a Lease" section


Dynamic DNS properties for the scope

"Configuring Dynamic DNS Update"

Selection Tags

Scope select tags for client classing

"Configuring Clients and Client-Classes"


Advanced scope settings

Various sections of this chapter

Creating Scopes

Create one or more scopes for each subnet. Each scope needs to have:


Policy that defines the lease times, grace period, and options

Network address (including its namespace) and its subnet mask

Range or ranges of addresses

Using the CLI

Use the scope name create command to create a scope with its network address and mask, the scope name set policy command to set its matching policy, and the scope name addRange command to add each scope's (space-separated) range of IP addresses. Each scope must identify its network address and mask. When you create the scope, Network Registrar places it in its current namespace (as defined by the session set current-namespace command). Follow with a server reload.

nrcmd> scope testScope create 
nrcmd> scope testScope addRange 
nrcmd> dhcp reload 

You can also explicitly set the namespace name or its ID by using the scope name set namespace, or scope name set namespace-id, command, respectively.

nrcmd> scope testScope set namespace=red 
nrcmd> scope testScope set namespace-id=123456 

You can attach individual options to a scope using the scope-policy command. You might want to do this to define just the router option for a particular scope. For a description of embedded policies for scopes, see the "Configuring an Embedded Policy for the Scope" section.

Using the GUI

Step 1 In the Server Manager window, choose the DHCP server for which you want to add a scope.

Step 2 Click Add on the toolbar.

Step 3 In the Add Scope dialog box (Figure 8-2), enter the name of the scope in the Name field. This name should reflect the scope's administrative intent and is case-insensitive (scope1 is the same as Scope1).

Figure 8-2 Add Scope Dialog Box

Step 4 You can associate only one policy per scope. In the Policy field, do one of the following:

Choose an existing policy from the drop-down list. The default policy appears initially. You can also choose the system_default_policy or any policy you create at the server level in the "Configuring Server Policies" section.

Create a new policy for the scope. Click View policy to open a DHCP Server Properties dialog box that includes just the Policies tab (Figure 7-2). Proceed as in the "Configuring Server Policies" section.

Step 5 In the Network number field, enter the network number of the scope's subnet. All scopes you create in the GUI are placed in the global namespace, that is, not part of any defined namespace.

Step 6 In the Subnet mask field, enter the subnet mask. In most cases, you would enter

Step 7 Enter the address range or ranges for the scope. Enter the first address in the Start Address column and the ending address in the End Address column for each range, but be sure the ranges do not overlap.

Timesaver Enter only the last octet of the start and end address. Entering an n value specifies the nth address in the subnet, based on the subnet mask.

Step 8 Click OK.

Step 9 Reload the server.

Using Multiple Scopes

You can configure multiple scopes (with disjoint address ranges) with the same network number and subnet mask. The DHCP server pools the available leases from all scopes on the same subnet and offers them, in a round-robin fashion, to any client that requests a lease.

You can configure a single subnet's addresses into multiple scopes to increase the speed that the GUI updates the Leases tab, or to organize the addresses in a more natural way for administration. Because each scope can have a separate reservations list, you might want to organize the leases into multiple scopes on the same subnet. Put the dynamic leases in one scope that has a policy with one set of options and lease times, and put all the reservations in another scope with different options and times.

You can also have multiple scopes with some not locally connected to your computer. In this case, configure the router (with BOOTP relay support) with the appropriate helper address.

When multiple scopes are available on a subnet through the use of secondary subnets, the DHCP server searches through all of them for a scope that satisfies an incoming DHCP client request. For example, if a subnet has three scopes, with only one supporting dynamic BOOTP, a BOOTP request for which there is no reservation in another scope is automatically served by the one supporting dynamic BOOTP. For details on secondary scopes, see the "Making a Scope a Secondary" section.

You can also configure a scope to disallow DHCP requests (the default is to allow them). By using these capabilities together, you can easily configure the addresses on a subnet so that all the DHCP requests are satisfied from one scope (and address range), all reserved BOOTP requests come from a second one, and all dynamic BOOTP requests come from a third. In this way, you can support dynamic BOOTP while minimizing the impact on the address pools that support DHCP clients.

The is no limit to the number of leases that you can configure per scope. However, if you have a scope with several thousand leases, it can take the Network Registrar GUI a while to sort them, although there is no impact on the server's operation. That is why it can be a good idea to divide the leases among multiple scopes.

Editing a Scope

You can edit a scope's properties.

Using the CLI

To look at the properties for all the scopes on the server, use the scope list (or scope listnames, scope name show, or scope name get attribute command). Use the scope name set command to set or reset an attribute, or the scope name enable, or scope name disable, command to enable or disable it.

nrcmd> scope list 
nrcmd> scope testScope get ping-timeout 
100 Ok
nrcmd> scope testScope set ping-timeout=600 
nrcmd> scope testScope enable ping-clients 

You can change the subnet and mask of the scope by using the scope name change-subnet command, and you can change just the mask by using the scope name changeMask command. This changes the primary-mask attribute on any secondary scopes, iterates over all reservations and ranges, and displays reservations and ranges that now fall outside the scope.

nrcmd> scope testScope change-subnet 
nrcmd> scope testScope changeMask 

Note Changing a scope's subnet and mask may result in a warning that certain address ranges have endpoints outside the scope.

Changing a mask:

Changes it on the specified scope.

Changes the primary-mask attribute on any secondary scopes to the specified scope.

Iterates over all reservations in the scope and displays any that now fall outside the scope. If reservations fall outside the scope, then the command returns "101, Ok with warnings" instead of "100 Ok."

Iterates over all ranges in the scope and displays any that have endpoints that now fall outside the scope. If range endpoints fall outside the scope, then the command returns "101, Ok with warnings" instead of "100 Ok."

At the next DHCP server reload, may delete existing leases that fall outside the acceptable ranges for this scope and are not in the acceptable ranges of any other scope. To have this occur, you must use the dhcp enable delete-orphaned-leases command in the CLI.

Also, see the "Making a Scope a Secondary" section.

Using the GUI

In the Server Manager window, double-click the scope under the DHCP server. This opens the Scope Properties dialog box (Figure 8-3). Change the properties on the applicable tabs of the dialog box, then click OK.

Figure 8-3 Scope Properties Dialog Box

Configuring an Embedded Policy for the Scope

When you create a scope, Network Registrar automatically creates an embedded policy for it. However, the embedded policy has no associated properties or DHCP options until you enable or add them. An embedded policy can be useful, for example, in defining the router for the scope. As the "Types of Policies" section describes, the DHCP server looks at the embedded policy of a scope before it looks at its assigned, named policy. The only way to configure an embedded policy is by using the scope-policy command attributes in the CLI.

Tip The GUI does not support configuring embedded policies. In the CLI, the scope-policy command uses the same commands as the policy command, except that it uses the scope name value.

Using the CLI

Step 1 Confirm if there are any embedded property values already set for a scope using the scope-policy scope-name show command.

nrcmd> scope-policy testScope show 

Step 2 Enable or disable an attribute using the scope-policy name enable or scope-policy name disable command, and set (and unset optional) properties using the scope-policy name set, and unset commands.

nrcmd> scope-policy testScope enable allow-lease-time-override 
nrcmd> scope-policy testScope set server-lease-time=2880 

Step 3 You can list, get, set, and unset DHCP options. You can also list, set, and unset vendor options. See the "Supporting Vendor-Specific DHCP Options" section.

nrcmd> scope-policy testScope listOptions 
nrcmd> scope-policy testScope setOption routers 

Step 4 Set and get the policy's lease time.

nrcmd> scope-policy testScope setLeaseTime 228800 
nrcmd> scope-policy testScope getOption dhcp-lease-time 
100 Ok

Step 5 If you delete a scope policy, you unset all of its properties.

nrcmd> scope-policy testScope delete 

Making a Scope a Secondary

Network Registrar supports multiple logical subnets on the same network segment, which are called secondary subnets. With several logical subnets on the same physical network, for example, and, you might want to configure DHCP so that it offers addresses from both pools. By pooling addresses this way, you can combine two class C networks, or a class B and C network.

To join two logical subnets, create two scopes, and elect one to be primary and the other to be a secondary. After you configure the secondary subnet, any client on this physical network gets 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.

Using the CLI

To make a newly created scope a secondary, use the scope name set primary-scope command to assign it to a primary, then reload the server. To remove the secondary scope status, use the scope name unset primary-scope command.

nrcmd> scope testScope2 create 
nrcmd> scope testScope2 addRange 
nrcmd> scope testScope2 set policy=internal 
nrcmd> scope testScope2 set primary-scope=testScope 
nrcmd> dhcp reload 

Using the GUI

Step 1 Create a scope to make it a secondary. See the "Editing a Scope" section.

Step 2 Open its properties.

Step 3 Click the Advanced tab.

Step 4 Check the "Make this scope a secondary" box.

Step 5 In the "Primary scope" field, choose the scope that you want to designate as the primary. This must be one of the other scopes for the server.

Step 6 Click OK.

Step 7 Reload the DHCP server.

Enabling and Disabling BOOTP for a Scope

The BOOTstrap Protocol (BOOTP) was originally created for loading diskless computers. It was later used to allow a host to obtain all the required TCP/IP information so that it could use the Internet. Using BOOTP, a host can broadcast a request on the network and get the data required from a BOOTP server. The BOOTP server listens for incoming 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 addresses that a BOOTP server allocates are permanent.

You can configure the Network Registrar DHCP server to act like a BOOTP server. In addition, although BOOTP normally requires static address assignments, you can choose either to reserve addresses (and use static assignments) or have addresses dynamically allocated (known as dynamic BOOTP).

When you need to move or decommission a BOOTP client, you can re-use its lease simply by forcing lease availability. See the "Forcing Lease Availability" section.

Using the CLI

Use the scope name enable bootp command to enable BOOTP, and the scope name enable dynamic-bootp command to enable dynamic BOOTP. Reload the DHCP server.

nrcmd> scope testScope enable bootp 
nrcmd> scope testScope enable dynamic-bootp 
nrcmd> dhcp reload 

Using the GUI

Step 1 Open the properties for the DHCP server containing the scope for which you want to enable BOOTP.

Step 2 On the Policies tab of the DHCP Server Properties dialog box, configure a policy to contain the information that BOOTP requires.

Step 3 Click Edit options. In the Edit Options dialog box, choose the options that you want. They are in the BOOTP Compatible category. Also, check the "Send to BOOTP clients" box. If you also check the "Always send to DHCP clients" box, the DHCP server always sends an option back in the reply packet.

Step 4 Click OK, then close the DHCP Server Properties dialog box.

Step 5 Open the properties for the scope for which you want to enable BOOTP and click the Advanced tab of the Scope Properties dialog box.

Step 6 Check the Enable BOOTP box.

Step 7 To have the server accept dynamic BOOTP requests for the scope, check the Dynamic BOOTP box. Dynamic BOOTP requests do not match a reservation, but can be satisfied from the available lease pool. If you do not want dynamic BOOTP, you must reserve the addresses. See the "Reserving a Lease" section.

Step 8 Click OK.

Step 9 Reload the DHCP server.

Disabling DHCP for a Scope

You can disable DHCP for a scope if you want to use it solely for BOOTP. See the "Enabling and Disabling BOOTP for a Scope" section. You can also temporarily de-activate a scope by disabling DHCP, but it is more often used if you are enabling BOOTP. See the "De-activating a Scope" section.

Using the CLI

Use the scope name disable dhcp command to disable DHCP. You should also enable BOOTP.

nrcmd> scope testScope disable dhcp 
nrcmd> scope testScope enable bootp 
nrcmd> dhcp reload 

Using the GUI

Open the properties of the scope for which you want to disable DHCP. On the Advanced tab of the DHCP Scope Properties dialog box, check the "Disable DHCP for this scope" box. If the "Enable BOOTP" box is unchecked, check it. Then, click OK. and reload the DHCP server.

De-activating a Scope

You may want to temporarily de-activate all the leases in a scope. To do this, you must disable both BOOTP and DHCP for the scope.

Using the CLI

Use the scope name enable deactivated command to disable BOOTP and DHCP for the scope. Reload the DHCP server.

nrcmd> scope testScope enable deactivated 
nrcmd> dhcp reload 

Setting a Scope to Renew-Only

You can control whether to allow existing clients to re-acquire their leases, but not to offer any leases to new clients. A renew-only scope does not change the client associated with any of its leases, other than to allow a client currently using an available IP address to continue to use it.

Using the CLI

Use the scope name enable renew-only command to set a scope to renew-only.

nrcmd> scope testScope enable renew-only 

Removing a Scope

You can remove scopes from the DHCP server.

Caution Although removing a scope from a DHCP server is easy to do, be careful. Doing so compromises the integrity of your network. There are several ways to remove a scope from a server, either by re-using or not re-using addresses, as described in the following sections.

DHCP, as defined by the IETF, provides an address lease to a client for a specific time (defined by the server's administrator). Until that time elapses, the client is free to use its leased address. A server cannot revoke a lease and stop a client from using an address. Thus, while you can easily remove a scope from a DHCP server, the clients that obtained leases from it can continue to do so until it expires. This is true even if the server does not respond to their renewal attempts, which happens if the scope was removed.

This does not present a problem if the addresses you remove are not configured for another server or not re-used in some way. However, if the addresses are configured for another server before the last lease expires, the same address might be used by two clients, which can cause serious errors.

Removing a Scope if Not Re-using the Addresses

If you do not plan to re-use the addresses from the scope, you can remove the scope from the server.

Using the CLI

Be sure you are not immediately planning to re-use the addresses in the scope, then use the scope name delete command to delete it.

nrcmd> scope testScope delete 

Using the GUI

Step 1 Look at the addresses in a scope in the Scope Properties dialog box. If you plan not to re-use the addresses, you can remove the scope.

Step 2 Click Cancel to exit the Scope Properties dialog box.

Step 3 Choose the scope in the Server Manager window.

Step 4 Click Remove on the toolbar.

Step 5 Click Yes in the confirmation dialog box.

Removing a Scope if Re-using the Addresses

If you want to re-use the addresses after removing a scope, you have two options:

If you can afford to wait until all the leases in the scope expire—Remove the scope from the server, then wait for the longest lease time set in the policy for the scope to expire. This ensures that no clients are using any addresses from that scope. You can then safely re-use the addresses.

If you cannot afford to wait until all the leases in the scope expire—Do not remove the scope. Instead, de-activate the scope. See the "De-activating a Scope" section. Unlike a scope that was removed, this causes the server to refuse all clients' renewal requests, which forces many of them to request a new lease. This moves these clients more quickly off the de-activated lease than if the scope had been removed.

Using the GUI, you can check the state of the de-activated scope's leases on the Leases tab in the Scope Properties dialog box. After they are no longer used, remove the scope and re-use the addresses.

You can also use the ipconfig utility in Windows to cause a client to release and re-acquire (renew) its leases, thereby moving it off a de-activated lease immediately. You can only issue this utility from the client machine, which makes it impractical for a scope with thousands of leases in use. However, it can be useful in moving the last few clients off de-activated leases in a scope.

Configuring Leases in the Scope

After setting the address ranges for a scope, you can monitor and adjust the leases that result from DHCP assignments.While there is no limit to the number of leases that you can configure per scope, if you have one with several thousand leases, it can take Network Registrar a while to sort them.

Viewing Leases

You can view the current state of leases for the scope address ranges.

Using the CLI

Use the lease list command to list all the leases in the cluster, or the lease name show command to show the properties of a particular lease. Use the scope name listLeases command to show all the leases for a scope. All show the same listing type.

nrcmd> lease list 
nrcmd> lease show 
nrcmd> scope testScope listleases 

You can show the most recent MAC address associated with a lease or what lease is associated with a MAC address. You can also list leases by LAN segment and subnet.

nrcmd> lease macaddr 
nrcmd> lease list -macaddr 1,6,00:d0:ba:d3:bd:3b 
nrcmd> lease list -lansegment 
nrcmd> lease list -subnet 

Using the GUI

Step 1 Double-click the scope for which you want to view leases. This opens the Scope Properties dialog box.

Step 2 Click the Leases tab (Figure 8-4).

Figure 8-4 Leases Tab (DHCP Scope Properties Dialog Box)

The Leases tab shows the following columns of information:

Address—Leases for the scope

State—Lease state

R—Reserved state flag

D—De-activated state flag

Host Address—MAC address of the DHCP client with the currently active lease

DNS Host Name—Hostname if you are not using dynamic DNS updates, or the name entered into DNS through dynamic DNS updates

Tip Click a column heading to sort the leases table by that column. Adjust each column horizontally by dragging a header separator line.

Lease States

A lease can be in one of the following states:


Unavailable—Not leasable. See the "Handling Leases Marked as Unavailable" section for ways the DHCP server might set a lease to unavailable.

Leased—Held by a client.

Offered—Offered to the client.

Expired—Available when the lease grace period expires.

De-activated—Not renewable or leasable after the lease expires. See the "De-activating a Lease" section.

Pending available—Failover-related. See "Configuring DHCP Failover."

Guidelines for Lease Times

To define appropriate values for lease times, consider the following events on your network:

Frequency of changes to DHCP options and default values

Number of available addresses compared to clients requesting them

Number of network interface failures

Number of computer removals for any purpose

Number of subnet changes by users

All these events can cause clients to release addresses or the leases to expire at the DHCP server. Consequently, the addresses return to the free-address pool for re-use.

If many changes occur on your network, assign a lease time of about four to ten days. You do not want the lease to expire over a weekend so that DNS name disappears and causes performance problems. Assigning such a lease time more quickly re-assigns addresses to clients that leave the subnet.

Another important factor is the ratio of available addresses to connected computers. For example, the demand for re-using addresses is low in a class C network having 254 available addresses of which only 40 are used. A long lease time, such as two months, would be appropriate in such a situation. The demand would be much higher had there been 240 to 260 clients connected at one time. In this situation, you should try to configure more addresses. Until you do, keep the DHCP lease time to under a hour.

Note Short lease periods require that the DHCP server be available when the client wants to renew the lease. This sets a need for backup servers.

Create policies that have permanent leases carefully. There is a certain amount of turnover among clients even in a stable environment. Portable hosts might be added and removed, desktop hosts moved, and network adapter cards replaced. If you remove a client with a permanent lease, you cannot re-use the address until you reconfigure the server. It would be better to create a long lease, such as six months, which ensures that addresses are ultimately recovered without administrator intervention.

Recommendations for lease durations include:

Set the cable modem lease time to seven days (604800 seconds). The leases should come from private address space, and the cable modems should seldom move around.

nrcmd> policy policyCableModem setOption dhcp-lease-time 604800 

Leases for customer premises equipment (CPE) or laptops should come from public address space and should match the habits of your user population, with as long a lease as possible to reduce load on the server.

nrcmd> policy policyPC setOption dhcp-lease-time 604800 

Shorter lease times require more response buffers. Set the request and response buffers for optimal throughput. There should be about three times as many response buffers as request buffers.

nrcmd> dhcp set max-dhcp-requests=1000 max-dhcp-responses=3000 

Importing and Exporting Lease Data

You can use the CLI to import lease data to and export from text files.

Using the CLI

The import leases, and export leases commands use the following file format. Each record, or line, in the file represents one DHCP client:


There are no spaces between the vertical line (|) delimiter and the field values. You must include at least the first four required fields. If including more, so you must delimit all the remaining null fields with the vertical line (|) so that there are 13 fields. The fields are, in order:

1. MAC address in aa:bb:cc:dd:ee:ff format (required)

2. MAC address type (required)

3. MAC address length (required)

4. IP address in dotted decimal format, a.b.c.d (required)

5. Start of lease time (Greenwich Mean Time, GMT) (optional)

6. Lease expiration time (GMT) (optional)

7. Allowable extension time (GMT) (optional)

8. Last transaction time (GMT) (optional)

9. IP address of the DHCP server (optional)

10. Hostname (without domain) (optional)

11. Domain name (optional)

12. Client ID (optional)

13. Namespace name (optional; if omitted, the global namespace is used)

For all the time fields, use either the number of seconds since 1970, or the day-month-day-time-year format (such as Mon Apr 10 16:35:48 2000).

When you use the export leases command, you can choose between writing the state of all current and expired leases, or just the current leases, to the output file.

Example 8-1 shows part of a lease data export from a Network Registrar DHCP server. The blank lines between records appear in the example for clarity; they are not in the actual output.

Example 8-1 Lease Data Export

00:60:97:40:c1:96|1|6||Wed Aug 30 08:36:57 2000|Fri Sep 01 13:34:05 2000|
Wed Aug 30 08:36:57 2000|Fri Sep 01 09:34:05 2000||nomad||

00:d0:ba:d3:bd:3b|1|6||Thu Aug 17 13:10:11 2000|Fri Sep 01 14:24:46 2000|
Thu Aug 17 13:10:11 2000|Fri Sep 01 10:09:46 2000||NPI9F6AF8||blue-namespace

00:d0:ba:d3:bd:3b|1|6||Fri Jun 23 15:02:18 2000|Fri Sep 01 14:11:40 2000|
Fri Jun 23 15:02:18 2000|Fri Sep 01 09:56:40 2000||JTB-LOCAL||blue-namespace

Pinging a Host Before Offering an Address

You can have the DHCP server use the Internet Control Message Protocol (ICMP) echo message capability (also used by ping) to see if anyone responds to an address before assigning it. The DHCP server checks that an address is not in use before assigning that address. Using ping can help prevent two clients from using the same address. If a client responds to the ping, the DHCP server marks that address as unavailable and offers a different address.

Tip A ping timeout period is a key element. Because pinging ensures that no client responds to a particular address, each ping waits the entire timeout period. This period comes before an offer is made, so that the time specified has a considerable effect on server performance. If you set this time too long, it slows down the lease offering process. Making the time too short reduces the effectiveness of the pinging process.

Using the CLI

Use the scope name enable ping-clients command to enable pinging clients before offering them an address. The default time interval to wait before assuming that no client will answer is 300 milliseconds. To change this, use the scope name set ping-timeout command. See the preceding note.

nrcmd> scope testScope enable ping-clients 
nrcmd> scope testScope set ping-timeout=200 

The server will make unavailable any address for which it receives a successful ECHO reply. You can control this by using the dhcp enable ignore-icmp-errors command, which is the default. If disabled, the DHCP server also treats ICMP DEST_UNREACHABLE and TTL_EXPIRED error messages that it receives after sending ICMP ECHO requests as grounds for making an address unavailable.

nrcmd> dhcp disable ignore-icmp-errors 

Using the GUI

Step 1 Open the properties for the scope.

Step 2 Click the Advanced tab of the DHCP Scope Properties dialog box (Figure 8-5).

Figure 8-5 Pinging Address Before Offering Option in DHCP Scope Properties Dialog Box

Step 3 Check the "Ping address before offering it" box.

Step 4 Choose a time to wait before assuming that no client will answer. The default is 300 milliseconds.

Step 5 Click OK.

Step 6 Reload the DHCP server.

De-activating a Lease

The reason you would de-activate a lease is to move a client off a lease. If the lease is available, de-activating the lease prevents Network Registrar from giving the lease to a client. If the lease is active (held by a client), de-activating the lease prevents the client from renewing it and it being given to another client. You can only de-activate a lease if the server is running. Network Registrar de-activates the lease immediately; you do not need to reload the DHCP server.

Tip To release a client's lease at their workstation, run the ipconfig utility with the /release option.

Using the CLI

Use the lease ipaddr deactivate command to prevent a lease from being given out or renewed. To re-activate a de-activated lease, use the lease ipaddr activate command.

nrcmd> lease deactivate 
nrcmd> lease activate 

Using the GUI

Step 1 Double-click the scope to open the Scope Properties dialog box.

Step 2 Click the Leases tab (Figure 8-4).

Step 3 Choose the lease that you want to de-activate.

Step 4 Click Lease properties (or double-click the address) to open the Lease Properties dialog box (Figure 4-3).

Step 5 Look at the Lease state information. If the lease is available, de-activating it makes it unavailable; if it is active, it becomes unavailable for both initial assignment and renewal.

Step 6 Check the "Deactivate lease" box.

Step 7 Click OK.

The Leases tab of the Scope Properties dialog box now shows the address as being de-activated, with an X in the D (De-activated) column.

To de-activate all the leases in a scope, you have to disable BOOTP and DHCP on the server. See the "De-activating a Scope" section.

Excluding a Leased Address from a Range

Addresses in a range need to be contiguous. You cannot delete a lease from a range, because it would than disrupt the range. Also, you must first de-activate the lease, then wait for it to become available. There is no wait if the lease is currently available. If the lease is active, it may take as long as the lease time plus the grace period. If you try to delete an active lease, Network Registrar returns a warning.

Caution Deleting an active lease can cause a duplicate address on the network if the deleted address is re-assigned. Information about that lease no longer exists when you reload the server.

Using the CLI

You can remove an address from a lease range simply by removing the range of just that address. The resulting ranges are then split appropriately. De-activate the lease first. Use the scope name listRanges, lease ipaddr deactivate, and scope name removeRange commands, then reload the server. The following example removes the address from the range.

nrcmd> scope testScope listRanges 
100 Ok start=; end=;
nrcmd> lease deactivate 
nrcmd> scope testScope removeRange 
nrcmd> dhcp reload 

Using the GUI

Step 1 In the Scope Properties dialog box, click the Leases tab (Figure 8-4) to find the address that you want to exclude from the range.

Step 2 De-activate the lease for the address, as in the "De-activating a Lease" section.

Step 3 Click the General tab (Figure 8-3).

Step 4 In the "Start Address-End Address" field, find the range to which the address belongs.

Step 5 Edit the address range so that it starts just after, or ends just before, the address you want to remove.

Step 6 Add another range to the table that adds back the addresses you edited out in the previous step, but excludes the address that you want to remove.

Step 7 Specify the address range, omitting the address of the lease that you want to delete.

Step 8 Click OK to close the Scope Properties dialog box.

Step 9 Open the dialog box and click the Leases tab to confirm that the address is gone. Click Refresh list.

Step 10 Click OK.

Step 11 Reload the DHCP server.

Reserving a Lease

To ensure that a client always gets the same lease, reserve the lease. You must reserve leases for DHCP clients whose addresses must remain constant.

Caution If multiple DHCP servers distribute addresses on the same subnet, the client reservations should be identical. If not, a client intended for reservation can receive multiple offers of different addresses from different servers.

To reserve a lease, match its address with the host's MAC address. You can choose any valid IP address on the network. It does not necessarily have to be in one of the scope's ranges. In fact, you can use the addresses in the scope's range for dynamic leases and the others not in the range for reserved leases.

Note Even though a reserved address may not be in the scope's range, the policy associated with the scope still applies to the address.

Using the CLI

Use the scope name listReservations command to list lease reservations for a scope. Use the scope name addReservation command to reserve a lease (including the IP and MAC addresses). Save the reservation, then you can send the reservation using the lease ipaddr send-reservation command. This does not require a server reload. Instead of saving and sending, you can also just reload the server.

nrcmd> scope testScope listReservations 
nrcmd> scope testScope addReservation 1,6,00:d0:ba:d3:bd:3b 
nrcmd> save 
nrcmd> lease send-reservation 
nrcmd> dhcp reload 

Using the GUI

Network Registrar provides two ways to make reservations using the GUI:

On the Leases tab

On the Reservations tab

Using the GUI Leases Tab Method

Step 1 Click the Leases tab (Figure 8-4) for the properties of the selected scope.

Step 2 Double-click the address of the lease you want to reserve.

Step 3 Check the "Reserve lease" box under Reservations.

Step 4 If the lease is available, enter the MAC address of the host in the "Reserved for MAC address" field. If the lease is active, the MAC address appears in the field because it needs to be defined to activate the lease. You can accept this MAC address or you can enter another one.

The hardware type and octet length of the MAC address is displayed as part of the MAC address in both the lease table and "Reserved for MAC address" field. The address prefix is usually "1,6," (meaning "use Ethernet and make the address six octets long"). When adding or editing a MAC address, you can include or omit this prefix (for example, 1,6,00:d0:ba:d3:bd:3b or just 00:d0:ba:d3:bd:3b), unless you want a different hardware type and address length. For details on the MAC address syntax, see the "Defining Client-Classes and Setting Their Properties" section.

Step 5 Click OK.

Step 6 Reload the DHCP server to make the reservations take effect.

Using the GUI Reservations Tab Method

Step 1 Click the Reservations tab (Figure 8-6) for the properties of the selected scope.

Figure 8-6 Reservations Tab (Scope Properties Dialog Box)

Step 2 Click Add.

Step 3 In the Add Reservation dialog box, enter the lease's IP address and MAC address.

You can include the hardware type and address length as part of the MAC address. The prefix is "1,6," (meaning "Ethernet and six octets long") by default, so you can omit it if the client uses Ethernet with the six-octet MAC address syntax. See the "Defining Client-Classes and Setting Their Properties" section. An example with the prefix is 1,6,00:d0:ba:d3:bd:3b.

Step 4 Click Apply to continue adding reservations, or click OK to finish.

Step 5 Click the Leases tab and click Refresh. There should be an X in the R (Reserved) column and the MAC address displayed for each address you reserved.

Step 6 Click OK.

Step 7 Reload the DHCP server.

Unreserving a Lease

You can remove lease reservations at any time. However, if the lease is still active, the client continues to use the lease until it expires. If you try to reserve the lease for someone else, you will get a warning.

Using the CLI

To remove the lease from the scope, use the scope name removeReservation command, indicating the client's MAC or IP address (note that if you omit it, this removes all lease reservations). Removing the reservation requires a server reload.

nrcmd> lease delete-reservation 
nrcmd> scope testScope removeReservation 
nrcmd> dhcp reload 

You can also combine removing a reservation with deleting it using the lease ipaddr delete-reservation command. This does not require a reload. The Network Registrar CLI Reference Guide includes a usage guideline in the lease command section on how to use these commands to reserve an address currently leased to another client.

Using the GUI

Step 1 Click the Reservations tab (Figure 8-6) for the properties of the selected scope.

Step 2 Choose the lease's IP address.

Step 3 Click Remove.

Step 4 Click the Leases tab to confirm removing the lease reservation.

Step 5 Reload the DHCP server.

Forcing Lease Availability

You can force a current lease to become available. You should request that the user release the lease, or do so yourself, before forcing its availability. Forcing lease availability does not require a server reload.

Using the CLI

Use the lease ipaddr force-available command to force making the currently held lease available.

nrcmd> lease force-available 

Use the scope name clearUnavailable command to force all leases in the scope to become available.

nrcmd> scope testScope clearUnavailable 

Using the GUI

On the Leases tab of the Scope Properties dialog box (Figure 8-4), choose the lease you want to force to become available. Double-click the address to open the Lease Properties dialog box (Figure 4-3). Then, click Force available and OK.

Handling Leases Marked as Unavailable

One of the aspects of effective lease maintenance is determining the number of unavailable leases in a scope. This number is sometimes higher than expected. The possible reasons and remedies are:

The DHCP server is configured for a ping before an offer, and the ICMP echo message is returned successfully—This indicates that there is a currently active client using that address, which the DHCP server marks as unavailable. To remedy this, disable pinging an address before offering it for the scope. See the "Pinging a Host Before Offering an Address" section.

The server receives a DHCPDECLINE message from a client to which it leased what it considered to be a good address—The client does an address resolution (ARP) for the address on its local LAN segment, and another client responds to it. The client then returns the address to the server with a DHCPDECLINE packet and sends another DHCPDISCOVER packet to get a new address. The server marks as unavailable the address that the client returns. If the client has a static address, configure it to use DHCP. If it keeps sending DHCPDECLINE messages, remove it.

The server receives "other server" requests from the client—Since all DHCPREQUEST messages that follow DHCPOFFER messages are broadcast, the server can see messages directed to other DHCP servers. A server knows that a message is directed to it by the value of the server-id option in the packet. If the Network Registrar server recognizes a message directed to another server, in that its own address does not appear in the server-id option, but the address is one that the server controls, it believes that two servers must be trying to manage the address simultaneously. It then marks the address as unavailable. This only happens in a non-failover configuration. Either the two servers are configured with some or all of the same IP addresses, or (in rare cases) there is a wrong server-id option value in the packet.

Network Registrar has a server attribute you can enable that turns this behavior off, the ignore-requests-for-other-servers attribute in the CLI:

nrcmd> dhcp enable ignore-requests-for-other-servers 

Inconsistent lease data—This is rare. It occurs while configuring a lease, when the server reads the lease data from disk during a refresh of the internal cache. The lease state shows as leased, but there is not enough data to construct a client for that lease. For example, it might not yet have a client-id option value. The server considers the data to be inconsistent and marks the address unavailable. The lease address force-available command should clear up this problem.

Running Address and Lease Reports

You can run the following reports on IP addresses and leases that are addressed in the following sections:

Address Usage—Displays the IP addresses used by a DHCP server

Lease Utilization—Displays statistics about leases in scopes

Lease Notification—Receive notification if available addresses in a scope fall below a certain level

Running an Address Usage Report

You can run an address usage report.

Using the CLI

Use the report command to display the IP address usage for specified servers. See the CLI Reference Guide for additional options you can set.

nrcmd> report dhcp-only 

Tip If you are not already using the lease-notification command in an automated way, try the lease-notification available=100% command for a quick and concise, scope-by-scope summary of the state of the servers.

Running a Lease Utilization Report

Using the CLI, you can generate a static and dynamic address usage summary on one or more clusters.

Using the CLI

The report command displays a row of information for each subnet specified by a scope or deduced from DNS static address assignments outside of scopes. It displays subtotal rows when more than one scope shares a common subnet, and when addresses share a common subnet, as specified by their address and mask. The report command assumes that there is no overlap between static addresses and scope ranges.

For each scope or subnet, the report command displays the following information:

Network number, in hexadecimal, based on the session's current namespace

Number of bits in the subnet mask

Network number in canonical dotted-octet format

For each scope-specified subnet, the report command also displays the following values:

Cluster name

Scope role—If using safe failover on a main or backup server

Scope name

Addresses—Total number of addresses within the scope ranges, addresses = free + dynamically leased + reserved + unavailable + de-activated + other available

Free—Addresses within a range and in the available state and not flagged reserved or de-activated

% free—As a percentage of all addresses within scope ranges

Reserved—Within a range and flagged reserved, unless unavailable

Leased—Within a range and in the leased, offered expired, or released state, even if flagged reserved or de-activated

Dynamically leased—Within a range and in the leased, offered, or expired state, unless flagged reserved or de-activated

Unavailable—Within a range and marked as unavailable by the server, regardless of flags

De-activated—Within a range and flagged de-activated, unless unavailable

Other available—Leases set aside for the safe failover partner to lease when communication is interrupted

Other reservations—Addresses marked reserved which are not within a scope range

Addresses have both a current state and a pending state after their lease expires. The categories leased and unavailable represent current states. The categories dynamically leased, reserved, and de-activated may represent current or pending states. The category free represents the current state available minus addresses that are flagged as reserved or de-activated. Note that the leased category overlaps other categories and is not incorporated in the scope total.

For each subtotal row, the report command provides summaries of any scope values in the subnet, and additionally, displays the following values:

Total—All addresses in the subnet.

Static—Addresses statically assigned.

Unallocated—Addresses unallocated to DHCP scope ranges, otherwise reserved or statically assigned, and therefore available for static assignment or allocation to a scope range.

Grand total—At the end of the report summarizes all the data in the subnets.

The comma-delimited text format is well suited for import into a database, spreadsheet or a similar tool. You can easily create customized reports.

Receiving Lease Notification

Using the CLI, you can survey all scopes on the Network Registrar clusters and produce a report of all the scopes in which the available addresses equals or falls below an absolute value or percentage.

Using the CLI

The lease-notification command specifies, through an available attribute, when the notification should occur if the number of available leases reaches or falls below a certain threshold. You can e-mail the report to a user. Although you can use the command interactively, its primary use is in an automated procedure such as a UNIX cron task or Windows Scheduled Task.

The following sets up lease notification for scope1 for when its free addresses fall to 10%. It sends the report to recipients billy, joe, and jane, on a specific Windows mail host.

nrcmd> lease-notification available=10% scopes=testScope recipients=billy,joe,jane 

The output consists of an explanatory header, a table containing a row for each scope in which the number of free addresses is equal to or less than the threshold, and possible warnings related to the scopes and clusters requested.

Network Registrar uses the default cluster and the .nrconfig file by default, unless you specify otherwise. For details on the command syntax, the configuration file syntax, and how to run the command in a procedure, see the lease-notification command in the CLI Reference Guide.

Recording IP Lease History

You can extract lease history data from a special database so that you can determine past allocation information for a given IP address. You can get an historical view of when a client was issued a lease, for how long, when the client or server released the lease before it expired, and if and when the server renewed the lease and for how long.

Network Registrar provides a client to control querying IP history data. Through this client, you can:

Get the MAC addresses associated with a given IP address over a given time.

See the entire IP history database as a comma-separated file.

You can use additional administrative functions to trim the IP history database of records, so as to keep the size of the database from growing without bounds.

Enabling IP History Recording

Using the CLI

You must explicitly enable recording IP (lease) history for addresses. Do so using the dhcp enable ip-history command. If enabling history recording, it is best to leave it enabled.

nrcmd> dhcp enable ip-history 

You must also specify the directory path to the root of the IP history database directory to effect enabling recording the IP history. It is best to store the history files on a different disk partition from the server's lease state database. That is why absolute paths are allowed. Relative paths are relative to the server logs directory. On Solaris and Linux, these are located in the /var/nwreg2/logs directory. On Windows, they are located in the C:\Program Files\Network Registrar\Logs folder. You specify the directory path using the dhcp set ip-history-dir command. Use forward slashes ("/") as path separators and quote paths containing space characters (as on Windows)

nrcmd> dhcp set ip-history-dir=/var/nwreg2/logs 

The DHCP server logs IP history recording errors in the usual DHCP log files. It also stops recording the history if the available free disk space drops below a certain point.

Running the IP History Query Utility

You can query the IP history database and direct the results to standard output or to a file by using the iphist utility. You must run this utility on the same machine as the DHCP server, and you must have root privileges to read and modify the database file. The location of the utility is as follows:

On Windows—\Program Files\Network Registrar\bin

On Solaris and Linux—/opt/nwreg2/usrbin

From the command prompt, change to the location and run the utility using the following syntax:

iphist [options] {ipaddress | all} [start-date | start [end-date | end]]

For example:

> cd /opt/nwreg2/usrbin 
> iphist -N user -P password -n red -o output.txt "12/12/2001 10:01:15" end 

The options are described in Table 8-3.

Table 8-3 iphistory Command Options 

This iphistory Command Option and Value...
Is or does the following...


Shows the lease attributes.

-n namespace

Name or ID or any associated namespace, or the word all (for all namespaces) or global (for addresses without namespace). If you omit this option, Network Registrar bases the query on the global namespace only, or the current one set by the session set current-namespace command, unless you use the all value with the option.

-o file

Output to a file rather than to the screen.

-f format

Format of output lines. See the "Formatting the IP History Query Output" section.

-N username

Administrator username. This option is required.

-P password

Administrator password. This option is required.

-V visibility

Sets the visibility (1 through 5) of the lease attributes. The default is 3.

The ipaddress is the IP address of the lease in dot-quad format, or all for all addresses. This argument corresponds with the address attribute of the lease object.

The start-date is the optional date for records from which to start the query, or the word start for the earliest date in the database. This argument corresponds with the start-time-of-state attribute of the lease object.

The end-date is the optional date of records the query should end, or the word end for the latest date in the database. This argument corresponds with the expiration attribute of the lease object. If using this argument, you must also use the start-date argument.

Dates can use the following syntax (quotes are required if space characters are included):

month/day/year@hour:min:sec (for example, 8/28/2001@10:01:15), with the time optional

month/day/year hour:min:sec (for example, "8/28/2001 10:01:15"), with the time optional

month day year hour:min:sec (for example, "Aug 28 2001 10:01:15"), with the time optional

The keywords start, end, or now (for the current time)

Formatting the IP History Query Output

The output from the iphist -f format command is a sequence of lines terminated with a newline sequence appropriate to the operating system (\n on UNIX or \r\n on Windows). Each line contains data on a single lease record. The format of the lines is generally comma-separated values enclosed in quotes. Within quotes, literal backslash (\) or quote (") characters are escaped with a single backslash (\). New lines in attributes are printed as \n.

The values on each line depend on the specific lease object that the DHCP server stores. You can specify the values to include or omit using the format argument in the -f option of the command. The format argument is a quote-enclosed and comma-separated list of lease attribute names that provides the template for the output lines. The default output is ipaddress,macaddress,start-time-of-state,
lease-expiration-time. You would specify this output using the lease object attributes, as follows:

ip-history> iphist -f "address,client-mac-addr,start-time-of-state,expiration" all 

Table 8-4 lists the lease object attributes you can include in the output. Also, see the lease command in the Network Registrar CLI Reference Guide for details.

Table 8-4 iphistory Query Output 

This attribute...
Is the following...


IP address of the lease.


Binary form of the client's MAC address.


Latest DNS name of the client known by the DHCP server.


Domain where the client resides.


A number of client flags.


Hostname the client requested.


Client ID requested by or synthesized for the client.


Date and time when the client most recently contacted the DHCP server.


MAC address that the client presented to the DHCP server.


Operating system of the leased client.


Date and time when the lease expires. This time is in GMT.


Either reserved or de-activated.


Minimal time in which the client is expected to issue a lease renewal. This time is in GMT.


Identifier for the namespace, if any.


Contents of the circuit-id suboption (1).


Contents of the option from the most recent client interaction.


Contents of the remote-id suboption (2).


Address in the server-id-override suboption.


Address in the subnet-selection suboption.


Contents of the vpn-id suboption.


Date and time when the lease changed its state. This time is in GMT.


One of available, expired, leased, offered, or unavailable.


Vendor class ID requested by the client.

Trimming IP History Data

If you enabled IP history trimming, you should regularly trim IP history database so that you can reclaim disk space. Each history record has an expiration time.

Using the CLI

The dhcp trimIPHistory command supplies the DHCP server with a cutoff time to apply to the history records. When you reload the server, it examines the history database and deletes any records with an expiration time older than the date-string value.

dhcp trimIPHistory date-string [-namespace name] [-logfile filename]

nrcmd> dhcp trimIPHistory "Tue Dec 31 19:00:00 2002" 
nrcmd> dhcp reload 

The effect of this command is not persistent; it only affects the next reload, not all subsequent reloads. You can specify to trim data in a specific namespace only. You can also redirect output to a log file that is placed in the log file directory, mainly for debugging purposes. Enter the date-string based on the local CLI time and date, in relative or fixed format:

-numunit—Relative date in the form of a hyphen followed by a num digit, and unit as one of s (seconds), m (minutes), h (hours), d (days), or w (weeks). For example, -12d, which indicates "twelve days ago."

"[day-of-week] month day hour:minute[:second] year"—This format must be enclosed in quotes, because it includes space characters. The (optional) day of week and the (required) month are abbreviated to the first three characters; the hour is on a 24-hour clock; seconds are optional; and the year is the fully specified year or a two-digit representation in which 98 = 1998, 99 = 1999, and all other values are in 20xx. For example, "Tue Dec 31 19:00:00 02".

You can get a true confirmation of the history data trimmed by running the iphist utility again and verifying the results, as described in the "Running the IP History Query Utility" section.

Querying Leases

Part of the implementation of the Cisco uBR access concentrator's relay agent is to capture and glean information from DHCP lease requests and responses. It does this so that it can:

Associate subscriber cable modem and client MAC addresses with server-assigned IP addresses.

Verify source IP addresses in upstream datagrams.

Encrypt unicast downstream traffic through the DOCSIS Baseline Privacy protocol.

Avoid broadcasting downstream Address Resolution Protocol (ARP) requests, which can burden the the uBR as well as the subscriber hosts, and which can be compromised by malicious clients.

The uBR device does not capture all DHCP state information through gleaning. The uBR device cannot glean from unicast messages (particularly renewals and releases) because capturing them requires special processing that would degrade the uBR device's forwarding performance. Also, this data does not persist across uBR reboots or replacements. Therefore, the only reliable source of DHCP state information for the uBR device is the DHCP server itself.

For this reason the DHCP server supports the DHCPLEASEQUERY message, which is similar to a DHCPINFORM message. The DHCPLEASEQUERY message's number in the dhcp-message-type option (53) is 13. The uBR device's relay agent sends a DHCPLEASEQUERY request to the DHCP server. The request always yields either a DHCPACK or DHCPNAK response from the server. A DHCP server that does not support this type of message is likely to drop the DHCPLEASEQUERY packet.

Lease Query Requests

In a DHCPLEASEQUERY request, the gateway IP address (giaddr) field must have the IP address of the requesting relay agent. The giaddr field is independent of the client address (ciaddr) searched and is simply the return address for any responses from the server.

The relay agent can send one of the following types of DHCPLEASEQUERY requests:

By IP address—The request packet includes an IP address in the client address (ciaddr) field. The DHCP server returns data for the most recent client to use that address. A packet that includes a ciaddr value must be a request by IP address, despite the values in the MAC address fields (htype, hlen, and chaddr) or the client-id option. This is generally the most efficient and should be the most widely used query method.

By MAC address—The request packet includes a MAC address in the hardware type (htype), address length (hlen), and client hardware address (chaddr) fields, and no value in the client address (ciaddr) field. The DHCP server returns all the IP addresses and most recent lease data for this MAC address in the associated-ip option of the DHCPLEASEQUERY packet. See the "Lease Query Responses" section.

By dhcp-client-identifier option (61)—The request packet includes a dhcp-client-identifier option value. The DHCP server returns a DHCPACK packet containing the IP address data for the most recently accessed client. If the request does not also include a MAC address, the server returns all addresses and their data for the requested dhcp-client-identifier. If the request includes the MAC address, the server matches the dhcp-client-identifier and MAC address with the client data for the IP address and returns that data in the client address (ciaddr) field or associated-ip option (161).

Lease Query Responses

The parameter-request-list option (55) in a DHCPACK response from the server should contain data pertinent to the requestor, such as dhcp-lease-time (51) and relay-agent-info (82) option values:

The dhcp-lease-time (51) value is for the remaining time until the lease expires.

The relay-agent-info (82) value is from the most recent DHCPDISCOVER or DHCPREQUEST message from the client to the server.

Network Registrar provides the following options for responding to DHCPLEASEQUERY messages:

cisco-client-last-transaction (163)—Contains the most recent time a server accessed the client.

cisco-client-requested-host-name (162)—Contains the host name that the client requested in the host-name option (12) or client-fqdn option (81).

cisco-associated-ip (161)—Contains data on all the IP addresses associated with the client.

Lease Query and Reservations

The DHCP server includes lease reservation data in DHCPLEASEQUERY responses. In previous releases of Network Registrar, the DHCPLEASEQUERY responses were possible only for leased or previously leased clients for which the MAC address was stored. Cisco uBR relay agents, for example, discard DHCPLEASEQUERY datagrams not having a MAC address and lease time (dhcp-lease-time option).

Network Registrar returns a default lease time of one year (31536000 seconds) for reserved leases in a DHCPLEASEQUERY response. If the address is actually leased, Network Registrar returns its remaining lease time.