Cisco Systems OL-6240-02 User Manual

CHA PTER

22

Advanced DHCP Server Properties

This chapter describes how to set up some of the more advanced DHCP server properties. Before clients
can use DHCP for address assignment, you must add at least one scope to the server. This is described
in Chapter 19, “Configuring Scopes and Networks.” The additional properties are:

• Configuring BOOTP, page 22-1

• Defining Advanced Server Parameters, page 22-3

• Integrating Windows System Management Servers, page 22-7

• Using Extensions to Affect DHCP Server Behavior, page 22-8

• Tuning the DHCP Server, page 22-10

• Configuring Virtual Private Networks and Subnet Allocation, page 22-12

• Setting DHCP Forwarding, page 22-19

• Setting DHCP Forwarding, page 22-19

Configuring BOOTP

BOOTP (the BOOTstrap Protocol) was originally created for loading diskless computers. It was later
used to allow a host to obtain all the required TCP/IP information to use the Internet. Using BOOTP, a
host can broadcast a request on the network and get information required from a BOOTP server. The
BOOTP server is a computer that listens for incoming BOOTP requests and generates responses from a
configuration database for the BOOTP clients on that network. BOOTP differs from DHCP in that it has
no concept of lease or lease expiration. All IP addresses that a BOOTP server allocates are permanent.

You can configure Cisco CNS Network Registrar to act like a BOOTP server. In addition, although
BOOTP normally requires static address assignments, you can choose to either reserve IP addresses
(and, therefore, use static assignments) or have IP addresses dynamically allocated for BOOTP clients.

About BOOTP

When you configure the DHCP server to return a BOOTP packet, be aware that BOOTP requires
information in the DHCP packet in fields other than the option space. BOOTP devices often need
information in the boot file (file), server’s IP address (siaddr), and server’s host name (sname) fields of
the DHCP packet (see RFC 2131).

OL-6240-02

Cisco CNS Network Registrar User’s Guide

22-1

Configuring BOOTP

Step 1 Decide which values you want for the BOOTP attributes:

Step 2 Decide the list of options and their values that you want returned to the BOOTP client.

Step 3 Set these values in the policy you want associated with the BOOTP request:

Chapter 22 Advanced DHCP Server Properties

Every Network Registrar DHCP policy has attributes with which you can configure the information you
want returned directly in the file, siaddr, or sname fields. The Network Registrar DHCP server also
supports a configuration parameter with which you can configure the policy options and determine
which of the file, sname, or siaddr values you want returned to the BOOTP device.

Network Registrar supports an analogous configuration parameter with which you can configure the
options and file, sname, or siaddr values you want returned to the DHCP client. This is in addition to
any options requested by the DHCP clients in the dhcp-parameter-request option in the DHCP request.
Thus, you can configure both the BOOTP and DHCP response packets appropriately for your devices.

• file—Name of the boot file

• siaddr—Server’s IP address

• sname—Optional server host name

• Attributes—Packe t-si addr, packet-file-name, packet-server-name to send to the BOOTP client.

• Option values, such as the server addresses and domain name to return to the BOOTP client.

• List of fields and options you want returned to the BOOTP client.

Step 4 Enable the associated scope or scopes for BOOTP processing.

Step 5 Enable dynamic BOOTP processing if you want to have this scope provide an address for any BOOTP

client that requests one. If you do not enable dynamic BOOTP, you must make reservations for each
BOOTP client for which you want this scope to provide an address.

Enabling BOOTP for Scopes

You can enable BOOTP processing for a scope. Set certain attributes and BOOTP reply options for a
created policy in the local cluster Web UI, or use policy name create and policy name set in the CLI, to
configure BOOTP. Set the policy attributes and options as a comma-separated list. The attributes are
entities to use in a client’s boot process:

• packet-siaddr—IP address of the next server

• packet-file-name—Name of the boot file

• packet-server-name—Host name of the server

The server looks through the policy hierarchy for the first instances of these attribute values.

In the CLI, policy name setOption requires spaces (not equal signs) before values. Also, enable BOOTP
and dynamic BOOTP, if desired, and ensure that the DHCP server updates the DNS server with BOOTP
requests. The options are:

• Set the option dhcp-lease-time.

22-2

• Enable the dynamic-bootp attribute.

• Enable the update-dns-for-bootp attribute.

• Enable the update-dns-for-bootp attribute.

Cisco CNS Network Registrar User’s Guide

OL-6240-02

Chapter 22 Advanced DHCP Server Properties

Moving or Decommissioning BOOTP Clients

When you move or decommission a BOOTP client, you can re-use its lease. To decommission a BOOTP
client, you must remove its lease reservation from the scope and force its lease to be available.

Force the lease available in the local cluster Web UI, or set scope name removeReservation and
lease ipaddr force-available in the CLI.

Using Dynamic BOOTP

When you use dynamic BOOTP, there are additional restrictions placed on the address usage in scopes,
because BOOTP clients are allocated IP addresses permanently and receive leases that never expire.

If you are using DHCP failover, when a server whose scope does not have the dynamic-bootp option
enabled goes into PARTNER-DOWN state, it can allocate any available IP address from that scope, no
matter whether it was initially available to the main or backup server. However, when the dynamic-bootp
option is enabled, the main server and backup servers can only allocate their own addresses.
Consequently scopes that enable the dynamic-bootp option require more addresses to support failover.

When using dynamic BOOTP:

Defining Advanced Server Parameters

1. Segregate dynamic BOOTP clients to a single scope. Disable DHCP clients from using that scope.

In the local cluster Web UI, under the BOOTP attributes for the scope, disable the dhcp attribute. In
the CLI, use scope name disable dhcp.

2. If you are using DHCP failover, set the failover-dynamic-bootp-backup-percentage attribute for the

DHCP server to allocate a greater percentage of addresses to the backup server for this scope. This
percentage can be as much as 50 percent higher than a regular backup percentage.

BOOTP Relay

Any router that supports BOOTP relay usually has an address that points to the DHCP server. For
example, if you are using a Cisco router, it uses the term IP helper-address, which contains an address
for a specific machine. In this case, use this address to forward all BOOTP (and therefore DHCP)
broadcast packets. Be sure that you configure this address on the router closest to your host.

Tip If your DHCP clients are not receiving addresses from the DHCP server, check the network

configuration, particularly the router or relay agent configuration, to verify that your network devices
are set up to point to your Network Registrar DHCP server address.

Defining Advanced Server Parameters

You can set advanced DHCP server parameters, including custom DHCP options.

Setting Advanced DHCP Server Parameters

Table 22-1 describes the advanced DHCP server parameters that you can set in the local cluster Web UI

and CLI.

OL-6240-02

Cisco CNS Network Registrar User’s Guide

22-3

Defining Advanced Server Parameters

Table 22-1 DHCP Advanced Parameters

Advanced Parameter Action Description

max-dhcp-requests set/

unset

Chapter 22 Advanced DHCP Server Properties

Controls the number of buffers that the DHCP server allocates for
receiving packets from DHCP clients and failover partners. If this
setting is too large, a burst of DHCP activity can clog the server with
requests that become stale before being processed. This results in an
increasing processing load that can severely degrade performance as
clients try to obtain a new lease, and affects the ability to handle
bursts. A low buffer setting throttles requests and could affect server
throughput. If the server runs out of buffers, packets are dropped.

A good rule or thumb is to increase the buffers if you expect a high
load (in a steady state or when experiencing frequent stress times)
or you have a fast multiprocessor system.

In a nonfailover deployment, the default setting (500) is sufficient.
In a failover deployment, you can increase it to 1000 if the DHCP
logs indicate a consistently high number of request buffers. You
should then also modify the number of DHCP responses (see the
max-dhcp-responses parameter) to four times the request buffers.

When using LDAP client lookups, buffers should not exceed the
LDAP lookup queue size defined by the total number of LDAP
connections and the maximum number of requests allowed for each
connection. Set the LDAP queue size to match the LDAP server’s
capacity to service client lookups.

Some log messages that might trigger a change in this value are:

4493 DHCP ERROR "DHCP has used xx of its yy request
buffers: the server is dropping a request."
4494 DHCP WARNING "DHCP has used xx of yy request packets.
Requests will be ignored if no packet buffers are
available."
5270 DHCP WARNING "DHCP has used xx of its yy request
buffers: the server is congested -- will not keep the
client last-transaction-time to within value but will keep
it to within value seconds."

22-4

Required. The default is 500.

Cisco CNS Network Registrar User’s Guide

OL-6240-02

Chapter 22 Advanced DHCP Server Properties

Table 22-1 DHCP Advanced Parameters (continued)

Advanced Parameter Action Description

max-dhcp-responses set/

unset

Defining Advanced Server Parameters

Controls the number of response buffers that the DHCP server
allocates for responding to DHCP clients and performing failover
communication between DHCP partners.

In a non-failover deployment, the default setting of twice the
number of request buffers is sufficient. In a failover deployment, you
can increase this so that it is four times the number of request
buffers. In general, increasing the number of response buffers is not
harmful, while reducing it to below the previously recommended
ratios might be harmful to server responsiveness.

Some log messages that might trigger a change in this value are:

4721 DHCP ERROR "DHCP has used all xx response packets. A
request was dropped and they will continue to be dropped
if no responses are available."
5289 DHCP WARNING "DHCP has used xx of yy response
packets. Requests will be dropped if no responses are
available."

max-ping-packets set/

unset

hardware-unicast enable/

disable

defer-lease-extensions enable/

disable

last-transaction-time­granularity

set/
unset

Required. The default is 1000.

Controls the number of buffers that the server has available to
initiate Ping requests to clients. If you enable the Ping address
before offering it option at the scope level, packet buffers are used
to send and receive ICMP messages. If you enable pinging, you
should have enough ping packets allocated to handle the peak load
of possible ping requests. The default is 500 ping packets.

Controls whether the DHCP server sends unicast rather than
broadcast responses when a client indicates that it can accept a
unicast. This feature is only available on Windows NT, Windows
2000, and Solaris platforms; other operating systems broadcast
instead. The default is enabled.

Controls whether the DHCP server extends leases that are less than
half expired. This is a performance tuning attribute that helps
minimize the number of disk writes to the lease state database. The
default is checked or true. This means that a client renewing a lease
less than halfway through can get the remaining part of it only and
not be extended. See the “Deferring Lease Extensions” section on

page 22-6.

Specifies the number of seconds that guarantees the last transaction
time to be accurate. This is a performance tuning attribute whereby
the server avoids frequent disk writes to the lease state database by
ignoring duplicate client activity (such as renews) within the set
granularity. Do not set this lower than 30 seconds. For optimal
performance, set it to a value that is greater than half the lease
interval. The default is 60 seconds.

OL-6240-02

Step 1 In the local cluster Web UI, click DHCP, then DHCP Server to open the Manage DHCP Serve page.

Cisco CNS Network Registrar User’s Guide

22-5

Defining Advanced Server Parameters

In the CLI, use dhcp show and dhcp get to show the current server parameters, then use dhcp set,
dhcp unset, dhcp enable, and dhcp disable to change them (see Table 22-1).

Step 2 In the Web UI, click the name of the server.

Step 3 In the Web UI, add or modify attributes on the Edit DHCP Server page.

Step 4 In the Web UI, click Modify Server to make the changes.

Deferring Lease Extensions

The defer-lease-extensions attribute allows the DHCP server to optimize its response to a sudden flood
of DHCP traffic. The parameter is enabled by default. An example of a network event that could result
in such a traffic spike is a power failure at a cable internet service provider (ISP) data center that results
in all of its cable modem termination systems (CMTS) rebooting at once. If this were to happen, the
devices attached to the CMTSs produce a flood of DHCP traffic as they quickly come back online.

When you enable the defer-lease-extensions attribute, a DHCP client that renews a lease that is less than
halfway to its expiration does not have its lease extended to an additional full lease time. Instead, the
client receives a lease corresponding to the remaining time on its existing lease. Because the absolute
lease expiration time does not change, the server can avoid database updates that result in a significantly
higher server throughput.

If a client is more than halfway to its expiration, this setting has no effect, and the lease is extended to
the full configured lease interval as usual, including the database writes.

Chapter 22 Advanced DHCP Server Properties

Note Deferring lease extensions significantly increases the server’s performance while remaining in

compliance with the DHCP RFC, which stipulates that client binding information is committed to
persistent storage when the lease changes.

When deferring lease extensions, it is advisable to leave the policy attribute allow-lease-time-override
to its default of disabled, or to change it to disabled if it is enabled.

These three specific situations are described from the server’s point of view:

• Client retries—When the server gets behind, it is possible for a client to retransmit requests. The

DHCP server does not maintain enough information to recognize these as retransmissions, and
processes each to completion, granting a full lease duration again and updating the database. When
the server is already behind, doing extra work worsens the situation. To prevent this, the DHCP
server does not extend leases that are less than 30 seconds old, regardless of the state of the
defer-lease-extensions attribute.

• Client reboots—The effective renew time for a client’s lease is really the minimum of the configured

renew time and the time between client reboots. In many installations this may mean that clients get
fresh leases one (in a typical enterprise) or two (in a typical cable network) times per day, even if
the renew time is set for many days. Setting the defer-lease-extensions attribute can prevent these
early renews from causing database traffic.

• Artificially short renewal times—Because there is no way for a DHCP server to proactively contact

a DHCP client with regard to a lease, you might configure short lease times on the DHCP server to
provide a means of doing network renumbering, address reallocation, or network reconfiguration
(for example, a change in DNS server address) in a timely fashion. The goal is to allow you to do
this without incurring unacceptable database update overhead.

22-6

Cisco CNS Network Registrar User’s Guide

OL-6240-02