Contents

The Cisco Network Registrar—Dynamic Host Configuration Protocol
(CNR—DHCP) server can be overwhelmed with requests in the event of a head end
reboot, like after a power failure and restore. These changes enable the DHCP
server to service requests more quickly and efficiently.

In this example, max-dhcp-requests is changed to 50.
The value of 50 might not be best. For example, if the CPU of your system is
low, the value of 50 might be high. There is not a mathematical formula to
calculate the best value. Use 50 to see if this is good for your system, and
make adjustments from there.

In most environments, reducing the
max-dhcp-requests value from 500 to 50 is the
best method to help the server react to long-term DHCP message bursts, such as
from many uBRs rebooting simultaneously.

When there is a head end reboot, the server may become overwhelmed with
requests. If you reduce the value of the
max-dhcp-requests, you can prevent the server
from storing too many messages in its receive queue, especially stale DHCP
messages. If the server keeps too many messages in the receive queue, it spends
more time processing stale DHCP message (which some clients drop and retry)
than recent DHCP messages (which all clients would accept). The optimal value
depends on:

server hardware

CPU

disk speed

network characteristics

The parameter max-dhcp-requests controls
the number of buffers that the DHCP server allocates to hold incoming requests.
After a head end reboot, all of the allocated buffers quickly fill up. After
the buffers are filled, the DHCP server throws away additional requests,
accepting new ones only as it processes requests and frees up buffers. The
server responds quickly to the first few requests that arrive. The next ones
remain in the buffer queue for several seconds. By the time the DHCP server
processes and responds, the client that sent the request has timed out.
Therefore, the resources of the DHCP server are wasted.

After a client times out, it retries, but the incoming buffer queue of
the DHCP server quickly fills. If the number of buffers is set so it takes more
than the four second client timeout to work through the queue and get to a
request, the response to the request comes too late. When the queue is full,
the clients, whose requests are discarded, retry.