A IPv4 lease can be in one of the states described in the table below.

A lease can be in one of the states described in the table below.

Lease date restrictions can be specified using the following attributes:

• lease-retention-max-age

• lease-retention-min-age

The lease-retention-max-age attribute specifies the longest time, in the past (from the current time), to which lease times are restricted. This can be used to meet data retention restrictions for privacy protection. If not specified, no restrictions are placed on how far back in time the lease times may be. In order for lease retention limitation to take place for a lease, not only does the lease-retention-max-age need to be non-zero, but the individual lease itself must fall under a policy where the lease-retention-limit attribute is set in that policy. This value, if configured, must be greater than 8 hours. If it is configured as non-zero and less than eight hours, it will be set to eight hours.

The lease-retention-min-age attribute specifies the shortest time, in the past, to which lease times may be restricted. Its value must be at least 6 hours less than the lease-retention-max-age. If this attribute is enabled and is configured to a non-zero value, lease times subject to retention limitation will not be allowed to grow older than lease-retention-max-age. As they progress toward lease-retention-max-age, they are periodically reset to lease-retention-min-age in the past. Configuring this attribute is optional as it will be six hours less than the lease-retention-max-age, by default. Also if the difference between the attribute values is less than six hours then lease-retention-max-age minus six hours is used.

Keeping older times on a lease between lease-retention-min-age and lease-retention-max-age involves some processing, and the closer these two values are, the more frequently this processing must take place, regardless of the absolute values of these attributes. Setting the lease-retention-min-age to several days before the lease-retention-max-age minimizes the additional server processing devoted to lease retention limitation.

You have to change one or more policies for the clients which are subject to these retention times. You can configure this in the system_default_policy to apply to all clients. But if there are some devices for which this does not matter, it might be best to configure it more selectively. The fewer the clients with this feature enabled, the lesser the impact on the performance of the server because of lesser work.

The policy attribute lease-retention-limit indicates whether the clients associated with that policy are subject to the lease date restrictions. If this attribute is enabled and the lease-retention-max-age of the DHCP server is configured to a non-zero value, lease times subject to this policy will not be allowed to grow older than lease-retention-max-age. As they progress toward lease-retention-max-age, they will periodically be reset to lease-retention-min-age in the past.

Some points to remember when considering to use the privacy protection feature are:

• When first enabled (or for certain reconfigurations), existing lease history records will not be subject to this feature because these records will not have the lease-retention-limit flag set.

• The lease history trimming time will likely be adjusted. It is set to about two-thirds of the difference between the lease-retention-max-age and lease-retention-min-age values. For example, when the default value of six hours is taken, the trimming is done every 4 hours.

• Disk Input/Output rates go up on the system. This is because the server needs to update the older times in the active and historical lease records. The impact of this can be reduced to some extent by increasing the difference between the lease-retention-max-age and lease-retention-min-age values.

• When configuration changes such as removing scopes and prefixes, or adjusting ranges are made, the leases associated with the scopes or prefixes become orphaned leases. These orphaned leases are not trimmed and not processed for privacy protection time limits. You must remove the orphaned leases. For more information, see Removing Orphaned Leases.

Bindings are new to DHCPv6 and allow multiple groups of addresses to be allocated to a client. A client binding consists of one of three types:

• Nontemporary (IA_NA)
• Temporary (IA_TA)
• Prefix delegation (IA_PD)

A binding also consists of a unique Identity Association Identifier (IAID). Leases always exist under a binding. Clients, therefore, have one or more bindings, and bindings have one or more leases. The server creates bindings when it first adds the lease, and removes the binding when it has no more leases. The server creates clients when adding the first binding, and removes them when it has no more bindings.

For DHCPv4, when a lease expires or the server releases it, the server remembers the client for an address as long as it is not assigned to another client. For DHCPv6, because of the large IPv6 address space and depending on the address generation technique, eons could pass before an address needs reassignment to another client. Therefore, Cisco Prime Network Registrar provides an affinity-period attribute so that the client can get the same address even if not requesting a renewal before expiration.

The affinity period is desirable in some environments, but not in others where the affinity time would be zero or very small. During the affinity period, the lease is in the AVAILABLE state and still associated with the client that last leased it. If the client requests a lease during this period, the server grants it the same lease (or, if renewals are inhibited, the client explicitly does not get that lease).

Leases have a life cycle controlled by states. A lease only exists while it is associated with a client and the server deletes it once it is no longer associated with that client. The life cycle and state transitions are:

1. A lease is born and associated with an address when the server:
   1. Creates a reservation for a lease, which puts the lease in the AVAILABLE state and marks it as RESERVED. No timer is associated with this state and the server does not delete the lease as long as it is RESERVED.
   2. Sends an ADVERTISE message to a client, which puts the lease in OFFERED state. The lease transitions to DELETED state after the offer timeout.
   3. Sends a REPLY message to a client (for a REQUEST, RENEW, or REBIND), which puts the lease in LEASED state. The lease transitions to EXPIRED state after the valid lifetime for the lease elapses.
2. An OFFERED lease transitions to:
   1. LEASED state when the server receives a REQUEST message, and then transitions to EXPIRED state after the valid lifetime for the lease elapses.
   2. DELETED state if the offered-time expires.
3. A LEASED lease:
   1. Is renewed when the server receives a REQUEST, RENEW, or REBIND message. The lease transitions to EXPIRED state after the new valid lifetime for the lease elapses (note that the new valid lifetime could be 0).
   2. Transitions to RELEASED state when the server receives a RELEASE message. The lease transitions to AVAILABLE state after the release-grace-period elapses.
   3. Transitions to UNAVAILABLE state when the server receives a DECLINE message. The server deletes the lease after the unavailable timeout period elapses.
4. An EXPIRED lease transitions to either AVAILABLE state after the grace-period. The server deletes the lease after the affinity-period elapses.
5. An AVAILABLE lease:
   1. Transitions to DELETE state and the server deletes it from memory and the lease database after the affinity-period elapses.
   2. Cannot be deleted if it is RESERVED, and it remains AVAILABLE.
6. The server can reoffer a LEASED, EXPIRED, RELEASED, or AVAILABLE lease to a client, but it remains in its current state, although the server extends the timeout to at least the offer-timeout.

The DHCP failover complicates some of the state transitions as these transitions can generally not occur until the partner acknowledges them. The additional life cycle and state transitions (failover related) are as follows:

• Transitioning into the AVAILABLE (or OTHER AVAILABLE) state requires that the partner to acknowledge the transition and hence the PENDING AVAILABLE state is used until the acknowledgement is received from the partner.
• Disassociating a lease from a client also requires an acknowledgement from the partner and hence the PENDING DELETE state is used until the partner has acknowledged the state change.

From the Design menu, choose Scopes under the DHCPv4 submenu to open the List/Add DHCP Scopes page, then click the Leases tab for the scope. This opens the page, where you can click each lease to manage it.

See Lease States for a description of the values in the State column. For guidelines as to the lease expiration time, see Guidelines for Lease Times.

To open the Edit DHCP Scope page, click the lease IP address.

From the Design menu, choose Scopes under the DHCPv4 submenu to open the List/Add DHCP Scopes page. You can then click the Leases tab for the scope; or you can click the name of the scope to open the Edit DHCP Scope page, then click Leases tab in the page.

Use lease [vpn-name/]ipaddr show to show the properties of a particular lease based on its IP address. Use scope name listLeases to show all the leases for a named scope. The output is nearly identical for both commands. Note that you cannot list leases in a particular virtual private network (VPN); all the leases in all the VPNs appear in the list.

You can show the most recent MAC address associated with a lease or what lease is associated with a MAC address. The lease [vpn-name/]addr macaddr command shows the MAC address of the lease, whether or not that lease is reserved or active. The lease list –macaddr addr [-vpn=vpn-name] command lists the lease data only if the IP address for that MAC address was actively leased (and not reserved). You can also list leases by LAN segment and subnet by using lease list -lansegment addr mask and lease list -subnet addr mask commands.

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

You can have the DHCP server use the Internet Control Message Protocol (ICMP) echo message capability (also known as ping ) to see if anyone responds to an IP address, before assigning it (using the ping-clients attribute). The ping-clients attribute controls whether the server should attempt to ping an address before offering a lease. If enabled, then the ping-timeout attribute may also need to be set.This test allows the DHCP server to check whether an address is not in use before assigning it.

Using ping can help prevent two clients from using the same address. If a client responds to ping, the DHCP server marks that address as unavailable and offers a different address. This test works only for powered-up clients; it is possible for clients to have a lease and be powered down.

You can also configure the ping-clients attribute at the DHCP server. This attribute controls the default value of the ping-clients attribute of a scope, if not explicitly configured on a scope.

Note	If you have configured scopes, the scope-specific configuration takes precedence; scopes without explicit configurations assume the global setting.

The ping timeout period is important. Because pinging helps to ensure that no client is using a particular IP address, each ping must wait the entire timeout period. This ping timeout period comes before an offer, so the time specified has a considerable effect on server performance.

• If you set this time too long, it slows down the lease offering process.

• If you set this time too short, it reduces the effectiveness of the ping packet to detect another client using the IP address.

To implement pinging hosts before offering IP addresses, modify the scope by:

• Enabling the ping-clients attribute. It is disabled by default.

• Setting the ping-timeout attribute. It is 300 milliseconds by default.

The server makes unavailable any IP address for which it receives a successful ECHO reply. You can control this action by enabling the DHCP server attribute ignore-icmp-errors (the preset value). If disabled, the DHCP server also uses ICMP DEST_UNREACHABLE and TTL_EXPIRED error messages that it receives after sending ICMP ECHO requests as reasons for making an IP address unavailable.

Deactivating a lease moves a client off of it. If the lease is available, deactivating it prevents the DHCP server from giving it to a client. If the lease is active (held by a client), deactivating it prevents the client from renewing it and the server from giving the lease to another client. You can deactivate a lease only if the server is running. The DHCP server deactivates the lease immediately.

Tip	To force a Windows client to release its lease, run ipconfig /release on the client machine.

Note

For DHCPv4 leases, the lease will remain deactivated until it is reactivated. For DHCPv6 leases (address or prefix delegation), the behavior is a bit different in that the lease will automatically be activated when the client is removed from the lease. Therefore, there is no need to activate DHCPv6 deactivated leases. However, this also means that the lease is available after the current lease ends and you cannot deactivate leases that are not associated with a client. If a DHCPv6 reservation is deactivated, it must be activated to be used by that client again.

IP address ranges, by definition, must be contiguous. To exclude a lease from an existing range, you must divide the range into two smaller ones. The new ranges consist of the addresses between the original starting and ending range addresses and the address that you want to exclude.

Caution

If the excluded address currently has an active lease, you should first follow the steps in Deactivating Leases, otherwise you will get a warning message. Deleting an active lease can result in a duplicate IP address if the deleted address is subsequently reconfigured and then reassigned. Information about that lease will no longer exist after you reload the server.

Using Cisco Prime Network Registrar, you can search for leases, server-wide. The search is a filter mechanism whereby you can specify a combination of lease attributes to target one or more leases configured for the network. The lease history search function is available at both local and regional cluster whereas the active lease search function is available only at the local cluster. The search function is provided separately for DHCPv4 and DHCPv6 leases.

You can also search for the active leases using Cisco Prime Network Registrar.

To restrict a scope to client reservations, do the following:

1. From the Design menu, choose Scopes under the DHCPv4 submenu to open the List/Add DHCP Scopes page. See Creating Scopes to create a scope.

2. Click enabled for restrict-to-reservations attribute in the Miscellaneous Settings group in the List/Add DHCP Scopes page.

   To modify an existing scope to specify client reservations, click the required scope name to open the Edit DHCP Scope page. Click enabled for restrict-to-reservations attribute in the Miscellaneous Settings group.

   The flag client-reserved shows that a scope is restricted to client reservations.

To restrict a scope template to client reservations, do the following:

1. From the Design menu, choose Scope Templates under the DHCPv4 submenu to open the List/Add DHCP Scope Templates page. See Creating and Applying Scope Templates to create a scope template.

2. Click enabled for restrict-to-reservations attribute in Miscellaneous Settings group in the List/Add DHCP Scope Template page.

   To modify an existing scope template to specify client reservations, click the required scope template name to open the Edit DHCP Scope Template page. Click enabled for restrict-to-reservations attribute in Miscellaneous Settings group.

To restrict a prefix to client reservations, do the following:

1. From the Design menu, choose Prefixes under the DHCPv6 submenu to open the List/Add DHCP v6 Prefixes page.

2. Click the Add Prefixes icon in the Prefixes pane, enter the prefix name and address and click the Add IPv6 Prefix.

3. Click the prefix name on the Prefixes pane to open the Edit DHCPv6 Prefix page. Click enabled for restrict-to-reservations attribute in Non-Parent Settings group.

   Note	Prefixes which have the restrict-to-reservations attribute enabled are not counted in the total of active leases which must be licensed. Any client which receives a client reservation will have that active lease counted, but that will happen only when the lease is actually held by a client.

To restrict a prefix template to client reservations, do the following:

1. To restrict a prefix to client reservations, from the Design menu, choose Prefix Templates under the DHCPv6 submenu to open the List/Add DHCP v6 Prefix Templates page.

2. Click the Add Prefix Templates icon in the Prefix Templates pane, to open the Add Prefix Template dialog box.

3. Enter the prefix template name and click the Add Prefix Template button.

4. Click enabled for restrict-to-reservations attribute.

   To modify an existing prefix template to specify client reservations, click the prefix template name that you want to restrict to client reservations. Click enabled for restrict-to-reservations attribute.

Client reservations have the following significant differences over lease reservations:

• There is no validation to assure that there is only a single client reservation for any address. If there are two different clients that specify the same address or prefix, whichever client request arrives first is granted that lease.

• A client reservation really exists only after the client completes DHCP configuration. Lease reservations are known even if a client transaction never occurs and thus can also be used for clients that do not provide DHCP services at all.

  Cisco Prime Network Registrar supports:

  • Creating a lease reservation for a particular IP address.

  • Configuring the correct cable modem MAC address for the IP address such that Cable Source Verify will work correctly with a Cable Modem Termination System (CMTS).

  This works because the Cisco Prime Network Registrar DHCP server knows about the lease reservation before any DHCP client transaction and will respond correctly to a leasequery request from a CMTS for those addresses. Client reservations are, in contrast, not known to the DHCP server before the arrival of a DHCP client packet at the DHCP server. A leasequery for an IP address which is configured as client-reserved due to some client registration will not (in general) know that the IP address is client reserved.

  Thus, any leasequery to which the DHCP server is supposed to respond with a positive result that includes the proper cable modem MAC address, even when no client has actively requested the lease, will not work with client reservations.

When the DHCP edit mode is synchronous, reservation changes are automatically forwarded to the DHCP server, and take immediate effect.

When the edit mode is staged, any change you make to the reservation list on a local cluster modifies the parent scope to indicate that a server reload is required. Any change to the regional reservation list modifies the parent subnet.

Reservations apply to nontemporary addresses and delegated prefixes only. They are associated with a prefix in the configuration, and must always be for an address (or prefix) under a configured prefix object.

The reservation can be outside the object range of the prefix, provided it is not in object range of another prefix. However, this has implications when you add a new prefix object. If a reservation that is contained in the new range of the prefix exists, the prefix will not be added. This results in an EX_CONFLICT status. For details, see Creating Lease Reservations.

Note	The operations for DHCPv4 reservations are similar to DHCPv6 reservations, except that the addresses are v6 addresses, not v4 addresses. Also, the main identity for a DHCPv6 client is a client DUID, and not the mac-address. DHCPv6 reservations include addresses and delegated prefixes.

Any change you make in the v6 reservation list modifies the parent prefix to indicate that a server reload is required. On the regional server, if the DHCP edit mode is synchronous and the parent prefix has been assigned to a local cluster, changes are automatically forwarded to the local cluster. A server reload is required, before these changes take effect.

Caution

If multiple DHCP servers distribute IP addresses on the same prefix, the reservations must be identical. If not, a client for whom a reservation exists can receive offers of different IP addresses from different servers.

A lease reservation pairs an IP address with a lookup key. A lookup key can be a string value or binary blob.

Note	If a new prefix delegation reservation is added that has a shorter or longer prefix that conflicts (is contained by or contained in) an existing lease when the server is reloaded, the reservation will prevent the existing leases from being loaded.

You can delete a reservation for one client while reusing it for another one, even though the first client still has the 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 a different client, you will get a warning.

Once you delete the last reservation from regional, it is not possible to select the reservation and push the change to the local cluster. You must push the parent subnet, which will then synchronize the reservation list and thus delete the local copy of the reservation.

There is no push function for DHCPv6 reservations in regional. You always need to push the parent prefix to resynchronize the reservations. This is the preferred method when synchronizing regional delete actions.

You might need to create lease reservations based on something other than the MAC address from the incoming client packet. Often, DHCP client devices attached to a switch port need to get the same IP address, regardless of the MAC address. This approach helps when you replace factory floor devices with identical devices (with different MAC addresses), but want to maintain the same IP address.

For DHCPv6 leases, you can send a RECONFIGURE message to a client to inform the client that the server has new or updated configuration parameters. If so authorized and through proper authentication, the client then immediately initiates a Renew, Rebind, or Information-request reply transaction with the server so that the client can retrieve the new data.

For more information on enabling the DHCPv6 policy reconfiguration, see Configuring DHCPv6 Policies.

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.

Note	After a lease is forced to be available, the client continues to use it until the client contacts the DHCP server.

Normally, the Cisco Prime Network Registrar DHCP server retains the association between a client and its leased IP address. The DHCP protocol explicitly recommends this association and it is a usually desirable feature. However, for some customers, such as ISPs, clients with long-lived lease associations may be undesirable, because these clients should change their IP addresses periodically. Cisco Prime Network Registrar includes a feature that allows customers to force lease associations to change when DHCP clients attempt to renew their leases or reboot.

A server can never force a client to change its lease, but can compel the client to do so based on a DHCPRENEW or DHCPDISCOVER request. Cisco Prime Network Registrar offers configuration options to allow customers to choose which interactions to use to force a client to change its IP address:

• Inhibiting all lease renewals —While a client is using a leased address, it periodically tries to extend its lease. At each renewal attempt, the server can reject the lease, forcing the client to stop using the IP address. The client might have active connections that are terminated when the lease terminates, so that renewal inhibition at this point in the DHCP interaction is likely to be user-visible.
• Inhibiting renewals at reboot —When a DHCP client reboots, it might have recorded a valid lease binding that did not expire, or it might not have a valid lease. If it does not have a lease, you can prevent the server from granting the last held lease. If the client has a valid lease, the server rejects it, forcing the client to obtain a new one. In either case, no active connections can use the leased address, so that the inhibition does not have a visible impact.
• Effect on reservations —Reservations take precedence over renewal inhibition. If a client has a reservation, it can continue to use the reserved IP address, whether or not renewal inhibition is configured.
• Effect on client-classes —Client-class testing takes place after renewal inhibition testing. If a client is forced to change IP addresses by renewal inhibition, then client-class processing might influence which address the server offers to the client.

You can enable or disable lease renewal inhibition for a policy, which you can set system wide, for a scope or on a client-by-client basis. The inhibit-all-renews attribute causes the server to reject all renewal requests, forcing the client to obtain a new IP address any time it contacts the DHCP server. The inhibit-renews-at-reboot attribute permits clients to renew their leases, but the server forces them to obtain new addresses each time they reboot. It applies only to DISCOVER and INIT-REBOOT operations. DISCOVER is included because few DHCP clients use INIT-REBOOT when they reboot (most clients just do a DISCOVER).

The DHCP server needs to distinguish between a client message that it should reject (such as a renewal request) and one that represents a retransmission. When the server processes a message, it records the time the packet arrived. It also records the time at which it made a lease binding to a client, and the last time it processed a message from the client about that binding. It then compares the packet arrival time with the lease binding time (the start-time-of-state) and processes packets from the client within a certain time interval from the start time of the binding. By default, this time interval is one minute.

There may be a need to move leases to a new DHCP server such as, the configuration of the server grows sufficiently large to exceed the recommended limits. There are different ways to accomplish this task depending on whether the leases are being moved to a new server or an existing server. Either of these techniques requires special considerations and careful execution. A new server is often the simplest way to accomplish by moving the entire configuration and the state database. To move the leases to another server, the leaseadmin utility is used. This utility allows you to export all or a selected set of leases and also to import this exported lease set.

Caution

The leaseadmin utility must only be used on a local cluster (exporting or importing) and the DHCP server must be stopped before running the leaseadmin utility.

The leaseadmin utility was added to Cisco Prime Network Registrar to allow leases to be moved from one server to another. You must run this utility on the same machine as the DHCP server and you must have superuser/root privileges to read and modify the database file. This utility requires direct access to the lease state database; however, stopping the DHCP server is not sufficient as the stopped server still holds the lease state database open. If the utility is run when the database is still in use, the leaseadmin utility will report the error "Failed to obtain exclusive access to lease state database". The default location is:

/opt/nwreg2/local/usrbin

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

./leaseadmin <options>

The table below describes the qualifying options for the leaseadmin utility.

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. Each unavailable lease is probably an indication of a serious problem. Possible causes for an unavailable lease are:

• The DHCP server is configured for a ping before an offer, and the ICMP echo message is returned successfully —A currently active client is using that IP address, causing the DHCP server to mark it as unavailable. To prevent the server from doing so, disable pinging an address before offering it to a client. See Pinging Hosts Before Offering Addresses.

• The server receives a DHCPDECLINE message from a client to which it leased what it considered to be a good IP address —The client does an address resolution (ARP) request for the IP 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. To prevent the server from reacting to DHCPDECLINE messages, you can set a scope attribute, ignore-declines.

• The server receives “other server” requests from the client —Because 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 Cisco Prime Network Registrar server recognizes a message directed at another server, in that its own IP address does not appear in the server-id option, but the address leased in the message is one that the server controls, it believes that two servers must be trying to manage the address simultaneously. It then marks the local address as unavailable. This behavior does not apply in a DHCP failover configuration. Either the two servers are configured with some or all of the same IP addresses, or (in rare cases) the DHCP client placed a wrong server-id option value in the packet.

  If you have reason to believe that the client is sending bad server-id options (rather than packets actually directed to other servers), Cisco Prime Network Registrar has a server attribute you can enable that turns this behavior off, the ignore-requests-for-other-servers attribute.

• Inconsistent lease data —Extremely rare and occurring only during server startup when, while configuring a lease, the server reads the lease data from disk during a refresh of the internal cache. The lease state appears as leased, but there is incomplete data to construct a client for that lease, such as that the lease might not yet have a client-id option value. The server considers the data to be inconsistent and marks the IP address as unavailable. Forcing the lease to be available (such as by using the lease ipaddr force-available command in the CLI) should clear up this problem.

During the times when leases become unavailable, as described in Handling Leases Marked as Unavailable, all unavailable leases remain in that state for a configured time only, after which time they again become available. A policy attribute, unavailable-timeout, controls this time. The system_default_policy policy sets this value to one day by default.

To handle upgrades from previous releases of Cisco Prime Network Registrar that do not have this timeout feature, a special upgrade timeout attribute, upgrade-unavailable-timeout (which is preset to one day) is included at the server level. The upgrade-unavailable-timeout value is the timeout given to leases set to unavailable before the Cisco Prime Network Registrar upgrade. This setting affects the running server only and does not rewrite the database. If the server stays up for one day without reloading, all the unavailable leases that were present at the last reload will time out. If the server reloads in less than a day, the entire process restarts with the next reload. Note that this process occurs only for leases that were set unavailable before the upgrade. Leases that become unavailable after the upgrade receive the unavailable-timeout value from the policy, as previously described.

The Cisco-proprietary and the more recent RFC-compliant implementations for DHCPv4 differ in only minor ways and will coexist. The DHCP server accepts Leasequery requests at the same port and returns the specified data for both implementations. The DHCPv6 implementation conforms with RFC 5007 and RFC 5460.

The DHCP server can include lease reservation data in Leasequery responses for DHCPv4 and DHCPv6. Cisco Prime Network Registrar returns a default lease time of one year (31536000 seconds) for reserved DHCPv4 and lifetime of the leases for DHCPv6 leases in a response. If the IP address is actually leased, Cisco Prime Network Registrar returns its remaining lease time.

Leasequery is preset to be enabled for all the implementations. To disable it, disable an Expert mode attribute, leasequery.

Leasequery messages usually contain request fields and options. To illustrate, suppose that after a relay agent reboot or replacement, the relay agent receives a request to forward a datagram downstream to the public broadband access network. Because the relay agent no longer has the downstream location data, it sends a LEASEQUERY message to the DHCP server that includes the gateway IP address (giaddr) of the relay agent and the MAC address or dhcp-client-identifier (option 61) of the target client. If the DHCP server finds the client, it returns the client IP address in the client address (ciaddr) field in the response to the leasequery. If the server cannot find the client address, it returns a DHCPNACK.

In the pre-RFC implementation for DHCPv4, the requestor can query by IP address, client ID option (61), or MAC address, and receives from the server a DHCPACK (with the returned data) or a DHCPNACK message, or the server drops the packet. If the request includes multiple query types, the DHCP server responds to the first one it can find. The giaddr value from the requestor is independent of the ciaddr searched and is simply the return IP address for any responses from the server. The three possible query types are:

• IP address ( ciaddr) —The request packet includes an IP address in the 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 dhcp-client-identifier option. Querying by IP address is the most efficient method and the one most widely used, in that the other two methods can put more load on the DHCP server.
• 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 omits a MAC address, the server returns all IP addresses and their data for the requested client ID in the cisco-leased-ip (also called the associated-ip) option. 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 ciaddr field or cisco-leased-ip (also called the associated-ip) option.
• MAC address —The request packet includes a MAC address in the hardware type (htype), address length (hlen), and client hardware address (chaddr) fields, and a blank ciaddr field. The server returns all the IP addresses and most recent lease data for the MAC address in the cisco-leased-ip (also called the associated-ip) option of the reply packet.

The DHCPLEASEQUERY message number in the dhcp-message-type option (53) for the pre-RFC implementation is 13. A server that does not support this type of message is likely to drop the packet. The DHCPACK message reply always contains the physical address of the lease owner in the htype, hlen, and chaddr fields. If the request contains the ciaddr, the data returned is always based on the ciaddr and never the client ID or MAC address.

The requestor can include the parameter-request-list option (55) to request specific options about an address. The reply often contains the dhcp-lease-time option (51) and the original content of the relay-agent-info option (82) that the client sent. If the server does not detect a valid lease for a client, it does not return option 51, and the requestor needs to determine if there is a valid lease.

A DHCPACK from the server can also contain the following Leasequery options:

• cisco-leased-ip (161) —Data on all the IP addresses associated with the client; also known as (and later renamed) the associated-ip option.
• cisco-client-requested-host-name (162) —Hostname that the client requested in the host-name option (12) or client-fqdn option (81). The requested hostname was dropped in the RFC 4388 implementation.
• cisco-client-last-transaction-time (163) —Most recent time duration that a DHCP server contacted the client.

Leasequery became an official RFC 4388 for DHCPv4 in February 2006. Cisco Prime Network Registrar provides the RFC 4388 implementation alongside the pre-RFC one (see Pre-RFC Leasequery for DHCPv4) and there are no conflicts between them. However, the RFC 4388 implementation includes a few notable changes:

• The DHCPLEASEQUERY message type contained in the dhcp-message-type option (53) changed its message ID to 10 (the ID 13 was given to the DHCPLEASEACTIVE message), and the reply messages were changed from just DHCPACK and DHCPNACK to be more specific:
  • DHCPLEASEQUERY (10) for queries
  • DHCPLEASEUNASSIGNED (11) for replies of unassigned addresses
  • DHCPLEASEUNKNOWN (12) for replies of unknown addresses
  • DHCPLEASEACTIVE (13) for replies of active addresses
• The reply option names and IDs changed, and the cisco-client-requested-host-name option was dropped so that there are only two reply options:
  • client-last-transaction-time (91) —Most recent time duration that a DHCP server contacted the client.
  • associated-ip (92) —Data on all the IP addresses associated with the client.
• If querying by client ID or MAC address, the request can contain only the dhcp-client-identifier option (61) or MAC address; if the packet contains both, the server drops it.

Cisco Prime Network Registrar supports both the RFC 5007 (UDP) and RFC 5460 (TCP, Bulk) DHCPv6 leasequery capabilities.

Note	To use the RFC 5460 (TCP, Bulk) leasequery support, you must create a DHCP Listener for IPv6 (see DHCP Listener Configuration).

The message types for DHCPv6 Leasequery are:

• LEASEQUERY (14)
• LEASEQUERY_REPLY (15)
• LEASEQUERY_DATA (17)
• LEASEQUERY_DONE (16)
• ACTIVELEASEQUERY(240)

A query can be by:

• QUERY_BY_ADDRESS (1)
• QUERY_BY_CLIENTID (2)
• QUERY_BY_RELAY_ID(3)
• QUERY_BY_LINK_ADDRESS(4)
• QUERY_BY_REMOTE_ID(5)

A DHCPv6 LEASEQUERY_REPLY message can contain one or more of the following options:

• lq-query (44) —Query being performed. The option, used in a request only, includes the query type, link-address (or 0::0), and options to provide data needed for the query.

• client-data (45) —Encapsulates the data for a single client on a single link. The client data can include any number of these or other requested options.

• clt-time (46) —Client last transaction time encapsulated in a client-data option (45); identifies how long ago (in seconds) the server last communicated with the client.

• lq-relay-data (47) —Relay agent data used when the client last communicated with the server. Fields are the peer-address and the relay-message. This option can include further options.

• lq-client-link (48) —Links on which the client has any bindings. Used in reply to a client query when the link-address is omitted and the client is found to be on more than one link.

• option_lq_base_time—Specifies the current absolute time on DHCPv6 server at the time of sending binding information.

A DHCPv6 LEASEQUERY_REQUEST message can contain one or more of the following options:

• option_lq_start_time—Bindings updated since the specified time. This option, used for the list of binding updates happened during the offline period.

• option_lq_end_time—Bindings updated during the specified time period.

DHCPv6 uses the Option Request option (oro) to request a list of options in the Leasequery reply.

Note	Leasequery by client-id requests may need to specify the override-client-id attribute when using [v6-override-client-id] expressions to correctly retrieve the information on the lease(s) for the client.

Lease queries provide statistics attributes, in the web UI, on the DHCP Server Statistics page (see the "Displaying Statistics" section in Cisco Prime Network Registrar 11.1 Administration Guide), and in the CLI by using dhcp getStats . The Leasequery statistics are:

• lease-queries —Number of RFC 4388 message ID 10 (or pre-RFC message ID 13) DHCPv4 Leasequery packets received in the given time interval.
• lease-queries-active —Number of RFC 4388 DHCPLEASEACTIVE packets.
• lease-queries-unassigned —Number of RFC 4388 DHCPLEASEUNASSIGNED packets.
• lease-queries-unknown —Number of RFC 4388 DHCPLEASEUNKNOWN packets.
• leasequeries —Number of DHCPv6 Leasequery packets received.
• leasequery-replies —Number of responses to DHCPv6 Leasequery packets that might or might not be successful.
• tcp-current-connections —Number of currently open TCP connections to the DHCP server for DHCPv6 Active and Bulk Leasequery.
• tcp-total-connections —Number of TCP connections that were opened to the DHCP server for DHCPv6 Active and Bulk Leasequery in this time interval.
• bulk-leasequeries —Number of LEASEQUERY packets received over all TCP connections in this timebulk-leasequeries interval.
• bulk-leasequery-replies —Number of LEASEQUERY-REPLY packets sent over all TCP connections in this time interval.
• bulk-leasequery-data —Number of LEASEQUERY-DATA packets sent over all TCP connections in this time interval.
• bulk-leasequery-done —Number of LEASEQUERY-DONE packets sent over all TCP connections in this time interval.
• tcp-lq-status-unspec-fail —Number of LEASEQUERY-REPLY packets with a status code of UnspecFail(1) sent over TCP in this time interval.
• tcp-lq-status-unknown-query —Number of LEASEQUERY-REPLY packets with a status code of UnknownQueryType(7) sent over TCP in this time interval.
• tcp-lq-status-malformed-query —Number of LEASEQUERY-REPLY packets with a status code of MalformedQuery(8) sent over TCP in this time interval.
• tcp-lq-status-not-configured —Number of LEASEQUERY-REPLY packets with a status code of NotConfigured(9) sent over TCP in this time interval.
• tcp-lq-status-not-allowed —Number of LEASEQUERY-REPLY packets with a status code of NotAllowed(10) sent over TCP in this time interval.
• tcp-lq-status-query-terminated —Number of LEASEQUERY-REPLY/LEASEQUERY-DONE packets with a status code of QueryTerminated(11) sent over TCP in this time interval.
• tcp-connections-dropped —Number of TCP requests that were terminated in this time interval because the TCP connection was closed (or reset) by the DHCPv6 requester. This excludes normal connection closes or server reloads.
• active-leasequeries—Number of ACTIVELEASEQUERY packets received over all TCP connections in this time interval.
• active-leasequery-replies—Number of LEASEQUERY-REPLY packets sent over all TCP connections in this time interval for active leasequery.
• active-leasequery-data—Number of LEASEQUERY-DATA packets sent over all TCP connections in this time interval for active leasequery.
• active-leasequery-done—Number of LEASEQUERY-DONE packets sent over all TCP connections in this time interval for active leasequery.
• tcp-lq-status-data-missing—Number of LEASEQUERY-REPLY packets with a status code of DataMissing(240) sent over TCP in this time interval.
• tcp-lq-status-catch-up-complete—Number of LEASEQUERY-DATA packets with a status code of CatchUpComplete(241) sent over TCP in this time interval.

The example below shows a packet trace of a DHCPv6 UDP query by client ID without a link-address, but with addresses on more than one link. The first part of the output shows the query message and the second part shows the reply data. The lq-query option identifies the type of query. Note the list of requested options via the Option Request option (oro) in the request, and the two addresses returned in the lq-client-links option in the reply.

+- Start of LEASEQUERY (14) message (113 bytes) 
| transaction-id 22
| lq-query (44) option (37 bytes)
| (query-type 2, link-address ::)
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:02:03:04:05:06
| oro (6) option (2 bytes)
| 47
| server-identifier (2) option (14 bytes)
| 00:01:00:01:13:06:6a:67:00:23:7d:53:e5:e3
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:03:05:07:09:11
| vendor-class (16) option (14 bytes)
| (enterprise-id 1760,
| ((00:08:41:49:43:20:45:63:68:6f)))
| vendor-class (16) option (14 bytes)
| (enterprise-id 1760,
| ((00:08:41:49:43:20:45:63:68:6f)))
+- End of LEASEQUERY message
+- Start of LEASEQUERY-REPLY (15) message (72 bytes)
| transaction-id 22
| server-identifier (2) option (14 bytes)
| 00:01:00:01:13:06:6a:67:00:23:7d:53:e5:e3
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:03:05:07:09:11
| lq-client-links (48) option (32 bytes)
| 2001:4f8:ffff:0:8125:ef1b:bdcb:4b4e,2001:4f8:ff00:0:e400:f92:1bfd:60fa
+- End of LEASEQUERY-REPLY message

The example below shows a packet trace of a DHCPv6 TCP query by client ID. The first part of the output shows the request message, the second part shows the response message with the binding data of the first client, and the last part will show that the query has ended successfully. The third part will follow the second part if there are more than a single client to be returned.

Note	The LEASEQUERY-DONE message will not be present in a packet if the LEASEQUERY-REPLY message does not have any binding data.

+- Start of LEASEQUERY (14) message (59 bytes)
| transaction-id 2
| lq-query (44) option (37 bytes)
| (query-type 2, link-address ::)
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:02:03:04:05:06
| oro (6) option (2 bytes)
| 47
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:03:05:07:09:11
+- End of LEASEQUERY message
 
+- Start of LEASEQUERY-REPLY (15) message (162 bytes)
| transaction-id 2
| server-identifier (2) option (14 bytes)
| 00:01:00:01:13:06:6a:67:00:23:7d:53:e5:e3
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:03:05:07:09:11
| client-data (45) option (122 bytes)
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:02:03:04:05:06
| clt-time (46) option (4 bytes)
| 5m54s
| iaaddr (5) option (24 bytes)
| (address 2001:4f8:ffff:0:8125:ef1b:bdcb:4b4e,
| preferred-lifetime 6d23h54m6s,
| valid-lifetime 1w6d23h54m6s)
| lq-relay-data (47) option (68 bytes)
| peer-address fcc0:a803::214:4fff:fec1:226a
| +- Start of RELAY-FORW (12) message (52 bytes)
| | hop-count 0,
| | link-address 2001:4f8:ffff::,
| | peer-address fe80::302:3ff:fe04:506
| | vendor-class (16) option (14 bytes)
| | (enterprise-id 1760,
| | ((00:08:41:49:43:20:45:63:68:6f)))
| +- End of RELAY-FORW message
+- End of LEASEQUERY-REPLY message
+- Start of LEASEQUERY-DATA (17) message (130 bytes)
| transaction-id 2
| client-data (45) option (122 bytes)
| client-identifier (1) option (10 bytes)
| 00:03:00:01:01:02:03:04:05:06
| clt-time (46) option (4 bytes)
| 5m33s
| iaaddr (5) option (24 bytes)
| (address 2001:4f8:ff00:0:e400:f92:1bfd:60fa,
| preferred-lifetime 6d23h54m27s,
| valid-lifetime 1w6d23h54m27s)
| lq-relay-data (47) option (68 bytes)
| peer-address fcc0:a803::214:4fff:fec1:226a
| +- Start of RELAY-FORW (12) message (52 bytes)
| | hop-count 0,
| | link-address 2001:4f8:ff00::,
| | peer-address fe80::302:3ff:fe04:506
| | vendor-class (16) option (14 bytes)
| | (enterprise-id 1760,
| | ((00:08:41:49:43:20:45:63:68:6f)))
| +- End of RELAY-FORW message
+- End of LEASEQUERY-DATA message
 
+- Start of LEASEQUERY-DONE (16) message (4 bytes)
| transaction-id 2
+- End of LEASEQUERY-DONE message

The address usage reports show the IP addresses that are assigned leases.

You can extract IP lease history data from a special database so that you can determine past allocation information for a given IP address. You can get a 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.

Cisco Prime 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.
• View the attributes of the lease history (the lease history detail report)—See Querying IP Lease History.

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

Note

When the state of an existing lease changes (for example, when it is configured as a reserved IP address or it is deactivated), the change does not appear as a lease history change at the regional. With detail collection disabled, a lease history change appears only when the lease transitions from leased to not leased or is assigned to another client.

You must explicitly enable lease history recording for the local cluster DHCP server. The DHCP server logs IP history recording errors in the usual DHCP log files.

When the lease history is enabled on a local cluster it impacts the performance of the server and the size of the lease state database. A history record is created for the lease whenever a lease ends (expires or is released); a lease that a client renews over a long period does not cause a history record to be created. The size of each lease history record depends on many factors, but a good estimate is about 1 KB per record. Depending on the rate at which the lease ends and the duration over which lease history is kept, this could result in a sizeable number of lease history records being created and thus requires a considerable disk space. This could be many orders larger than the space needed for the active leases.

Once you have leases, you can query for their history. You can query IP lease history either from a local or a regional cluster. Set up the local cluster containing the DHCP server as part of the regional cluster, and enable polling for the lease history data from the regional cluster (see the "Enabling Lease History Collection" section in Cisco Prime Network Registrar 11.1 Administration Guide).

You can adjust the polling criteria for the cluster in the regional cluster web UI by using the attributes described in the "Polling Utilization and Lease History Data" section in Cisco Prime Network Registrar 11.1 Administration Guide.

You must also set the selection criteria for querying the lease history data, as described in the following sections.

If you enabled IP history trimming at the regional cluster, the IP history database is automatically trimmed so that you can reclaim disk space. Each history record has an expiration time. Trimming is necessary for the DHCP server itself, as well as for the CCM regional server that polls the DHCP server for history data.

The CCM server performs background trimming at the regional cluster, which trims off the lease history data older than a certain age at regular intervals. The trimming interval is set by default to 24 hours, and the age (how far back to go in time before trimming) to 24 weeks. The DHCP server at the local cluster performs daily automatic trimming (at 3:00 A.M. local time), and stores four weeks of data by default.

Lease utilization reports show the current utilization of address blocks, subnets, and scopes. For both user interfaces, see Generating Utilization History Reports.

The CLI provides the feature of sending notifications if the number of available IP addresses equals or falls below a certain threshold. 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.

nrcmd> lease-notification available=10% scopes=examplescope recipients=billy,joe,jane
mail-host=mailhost

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.

Cisco Prime Network Registrar uses the default cluster and the .nrconfig file by default, unless you specify otherwise. For the command syntax, see the help for the lease-notification command.

To use Dynamic Lease Notification:

1. You must create a dhcp-listener object on the local cluster. The dhcp-listener object specifies the port on which the server listens for incoming TCP connections and other attributes for these connections (see DHCP Listener Configuration). You must reload the DHCP server after creating the dhcp-listener object.
2. A dynamic lease notification client must establish a TCP connection with the DHCP server and make any of these requests:
   • Bulk leasequery—This request is made to obtain the current state of all leases in the DHCP server that have changed state since a specific point in time. The current state of all leases is sent when no time is specified (or zero is specified for the time). This is similar to the UDP-based DHCPv4 leasequery (RFC 4388) and DHCPv6 leasequery (RFC 5460), except that the DHCP server delivers all leases to the client in response to a single request. Typically, a bulk leasequery is used to initialize an external database. It is also used to bring that database up to date after some interruption of an active leasequery, where the catch-up time was too great for the active leasequery to return the missed data.
   • Active leasequery—This request is made to obtain lease state information for all future significant lease changes that the DHCP server will make. When the DHCP server writes significant lease state information to its database, the lease state information will be sent over the TCP connection.
   • Active leasequery with catchup—This request is made to obtain future lease state changes and the latest data from recently changed leases. It allows the dynamic lease notification client to retrieve the latest data on recently changed leases that were missed during a short period of connection loss, such as during a restart of the dynamic lease notification client or DHCP server. The active leasequery with catchup fetches only the current state of a lease; it does not fetch the data on all intermediate lease state changes that might have been missed.

The DHCP server sends the lease state information to the dynamic lease notification client in a stream of leasequery messages. For a bulk leasequery, the lease state information is sent as soon as the DHCP server has time for processing. For an active leasequery, the lease state information is sent as lease state changes occur. The dynamic lease notification client can process these messages to take appropriate actions such as updating its database.

Note	While the DHCP server supports multiple dynamic lease notification clients, it is recommended to keep the number of clients to a minimum as multiple clients can impact the DHCP server's leasing performance.

In a failover configuration, only the active failover partner which interacts with the DHCP client sends dynamic lease notification updates to the dynamic lease notification clients with an active leasequery request. Therefore, to receive complete information, a dynamic lease notification client must connect to both the failover partners.

The server determines whether a lease is queued for active leasequery notifications based on the leasequery-send-all attribute of the dhcp-listener. If this attribute is enabled, the DHCP server always sends a notification to an active leasequery client. If this attribute is disabled or unset, the DHCP server only sends notifications which are necessary to maintain accurate state in the active leasequery client.

You can also control the leasequery notifications using extensions. Extensions can decide whether a lease is queued for active leasequery notifications using the active-leasequery-control request and response data dictionary items as described in Using Extension Points.

Using DHCP Listener Configuration, you can configure objects to enable active and bulk leasequery to the DHCP server over TCP connections. A single object is sufficient, unless you want the DHCP server to support listening for connections on multiple TCP ports or need to restrict the addresses on which the server will accept incoming connections.

Caution

Follow every step in this procedure carefully. If you skip any step, you might lose lease history data. Note the lease history database that each task involves. Depending on the number of lease history records and the time taken to trim or merge the records, this utility may take several hours or days to run. You can interrupt the utility while it is running if the server reboots before the run is completed. You can resume it later; however, you must specify the same options that you have used in the previous run.

The install-path is the path in which you install Cisco Prime Network Registrar.

The table below describes the qualifying options for the cnr_leasehist_compress utility.

+00:00:18 Read 100000 records (0 bad); trimmed 6717; merged 73370; 19912 written (19.91%)

In Cisco Prime Network Registrar, you can schedule the maintenance window, so that it is less prone to errors and forgetting to reset lease times. You can configure the start time, end time, and refresh period of the desired maintenance window. Also, you can specify whether the maintenance window is server wide or applies only to specific scopes, links, or prefixes. The server tries to adjust lease, renewal (T1), and rebinding (T2) times to avoid the client's attempt to contact the DHCP server between the start and end time of the maintenance window, as the server may shutdown during this period. During the maintenance window, the DHCP server uses the minimum lease time and after the maintenance window, it ramps up lease time to original, but keeps the renewals spread out. The renewals during and after the reconfiguration are well distributed to minimize any server load spikes. You can eventually remove the maintenance window configuration or replace with a new configuration. The server ignores the maintenance that occurred in the past.

Maintenance Window shows three clients with different lease times, interacting with the maintenance window. In the first (top) case, there is no change as client is coming in during the renewal period. In the second (middle) case, the server shortens the times to assure the client renews during the renewal period. In the third (bottom) case, the server increases the times to avoid client renewal during the maintenance window (as server may not be reachable).

You can create, edit, and delete a single maintenance window, which means that, there can be only one possible maintenance window at a time in the server. The DHCP server will load the maintenance window if configured. It will ignore to load the maintenance window if the current time is after the end time plus the renewal period (time interval after the end of the maintenance window by which all clients should have the updated configuration). Also, it will not load if the distributing of lease renewals is not enabled (see Distributing Lease Renewals). For scopes, links, or prefixes to which the maintenance window applies, the server will alter the lease and/or renewal times sent to clients as follows:

• Any lease time given to a client before the end of the maintenance window will not exceed the end time of the maintenance window plus the renewal period.

• Any renewal time given to a client before the end of the maintenance window will not exceed the end time of the maintenance window plus 1/2 the renewal period.

• Any lease time given to a client that ends between the start and end time of the maintenance window will be adjusted to expire somewhere between the end of the maintenance window plus 1/2 the time interval after and before the end time plus the interval after.

• Any renewal time given to a client that occurs between the start and end time of the maintenance window will be adjusted to trigger a renewal somewhere between the end of the maintenance window and 1/2 of the renewal period.

Note	Failover time restrictions continue to apply and are not altered because of the maintenance window. These restrictions may prevent the server from optimizing the lease, renewal (T1), and rebinding (T2) times for some clients.

The DHCP server adjusts the client renewals to ensure that the lease renewal load is as evenly distributed as possible and thus to avoid spikes in renewal traffic. Renewal traffic spikes can occur after a maintenance window, network (or power) outage where a large number of clients return at once. This feature is enabled by default to avoid these spikes.

The server maintains the count of the number of clients renewing within a bucket interval. When the server determines a renewal time for a client (50% of lease time), it checks whether the value of that bucket exceeds the norm (number of clients / (latest renewal time-current time / bucket interval) rounded up). If the norm is exceeded, the server picks a random value between 20% and 120% of the renewal time, and will check that bucket against the norm. This process is repeated a limited number of times until a bucket is found that is below the norm, or if not, the time for the bucket with the lowest count is used.

Note	The server does not adjust the count if a bucket is less than 10 renewals/second, as the server can easily handle that load.

Distribute Lease Renewals Example shows an example of the distribute renewals feature. In this example, the server adjusts renewal time if bucket at client's normal renewal time (50% of lease time of 1800 seconds = 900 seconds) exceeds the threshold of expected clients renewing in that bucket's period. Here, the server picks a random alternative renewal time (between 20% to 120% of original renewal). But, first try also exceeds threshold, so a secondary try is attempted, which finds renewal time (944) that is in a bucket which is below the threshold. Client is given that renewal time (944 seconds).

For DHCPv4, when this feature is enabled, the server will force sending the dhcp-renewal-time option (58) and the dhcp-rebinding-time option (59). For DHCPv6, the server always sets the T1/T2 fields in the IA_NA and IA_PD options, so there is no impact to that processing.