CNR 6.1.2 request bufffers incrementing until it reaches 500

[pmeyer123]

Hi, We are running Cisco CNR 6.1.2  build #6.1.2.0501131448 and this has been very reliable for over 5 years, just recently in the last 4 weeks have began experiencing a problem where the DHCP server will stop issuing leases in response to discovers. A reload of the dhcp application fixes the problem.

In troubleshooting I see in the name_dhcp_1_log where during normal operation the log indicates that the request buffers have 2 or 3 in use at any one time. I will see a DHCP DISCOVER, or REQUEST come in and at the end of the entry it will show "3 in use" or "2 in use" and toggles between 2 and 3, then _something_ occurs and I begin to see the DISCOVER, and REQUEST entries will indicate that the buffers "in use" is incrementing... "4 in use" 5 in use" etc, until at some point the server will stop serving out leases in response to those DISCOVERS and REQUESTS. The request buffer size is set to 500 ( default) and the response buffer is set to 1000 ( default to twice the size of request buffer) and ultimately the log entries will indicate that the buffers in use will continue to increment until it reaches 500.

Again, this application has been running silently fo over 5 years without this issue, I dont know if some recent DHCP activity is causing this problem, or if it is some recent corruption to the CNR application, or a problem with the OS ( running solaris 8 )

Has anyone see anything similar, or have any ideas on what I might check?

Thanks

Paul

[pefrench]

Hi Paul,

Check out this known bug:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsf98245

Release-note:
===
In the event that a lease to a client is denied because the server is configured to use
limitation-counts, and the limitation-count for this limitation-id (i.e., subscriber) has
been exceeded and there is no over-limit-client-class, then if (and only if) there is a
dhcp-requested-address option in the request packet and the IP address specified is not
configured in the same Network as the giaddr specified in the DHCPDISCOVER, then the DHCP
server will not properly release the request packet after it concludes the processing.
Eventually the DHCP server will use up all of its configured request packets and will
hang.

This will result in an increasing "in-use" count in the activity summary and in the
incoming-requests log message (number 04619).  This problem can only occur if message
number 05646 appears, but it will not always occur when this message appears. It will only
occur when message 05646 appears and when the dhcp-requested-address option also contains
an IP address not in the current Network configuration.

The workaround for this problem is to give the client-class which contains the
limitation-id an over-limit-client-class, and to also ensure that  the
over-limit-client-class specifies a selection-criteria that does not exist in any scope.
This will cause the packet to be dropped, not because there is no overlimit client-class
(message number 05646) but because there are no scopes which satisfy the criterion
specified in the over-limit-client-class (message number 04441).

Fixed in 6.1.6. HTH. Else a TAC case might be warranted.