CNR Parameter Changes with Multiple Cable Modems in a Network

Available Languages

Updated:October 26, 2005

Document ID:11094

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

Changes to DHCP

Explanation

Related Information

Introduction

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.

Prerequisites

Requirements

The reader should have a basic understanding of the DOCSIS protocol and Cisco IOS command line on the uBR series routers.

Components Used

The hardware use in this document were from the Cisco uBR7200, uBR7100 or uBR10k CMTS and DOCSIS compliant cable modems.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Changes to DHCP

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.

Explanation

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.