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.
The reader should have a basic understanding of the DOCSIS protocol and Cisco IOS command line on the uBR series routers.
The hardware use in this document were from the Cisco uBR7200, uBR7100 or uBR10k CMTS and DOCSIS compliant cable modems.
For more information on document conventions, see the Cisco Technical Tips Conventions.
Make the following change to the DHCP configuration:
nrcmd> dhcp set max-dhcp-requests=50
Save this configuration change:
nrcmd> save
Re-start the server with:
nrcmd> dhcp reload
Caution: Besides this particular parameter, be cautious about adjusting server parameters in the field. Refer to DHCP.
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.