CNR 6.1.2 request bufffers incrementing until it reaches 500
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?
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.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
Introduction Prepositioning is a powerful tools on the WAAS platform but
it is not always easy to figure out why your jobs are failing when
trying to retrieve the files.Here is a method that should help you to
figure out the reason why they are not succes...