Watching performance on a DHCP Server

[Blake Hudson]

-------- Original Message  --------
Subject: Re: Watching performance on a DHCP Server
From: Simon Hobson <dhcp1 at thehobsons.co.uk>
To: dhcp-users at isc.org
Date: Sunday, April 27, 2008 1:41:45 AM
> Anders Rosendal wrote:
>
>> The biggest problems with intensive DHCP-storms due to network 
>> outages longer then leasetime is that if the server, or cluster of 
>> servers is not quick enough to provide answers is that the request 
>> made by the clients times out before the client receives a answer 
>> from the server. This causes the server to only answer requests that 
>> are "old" and no clients receives there addresses. The solution to 
>> implement when stuck in this situation is to block requests in the 
>> routers for large part of the network, and then bit by bit opening up 
>> everything again. On the company which I work we have an inhouse 
>> built DHCP-server which is quite powerful, we have ~550000 leased 
>> IP's in the system. Althoug when we have had long outages we have 
>> been forced to used the solution described above. You should monitor 
>> the udp-in-queue on the server / servers, checking that the server 
>> manages to answer clients quickly enough.
>
>
> Does this mean that a smaller udp queue would be better ? Ie, throw 
> away excess requests (the client will try again soon) rather than 
> allow them to get stale ?
>
> Or in some situations, rate limiting DHCP packets in the routers ?
>
If you randomly drop packets you become more likely to lose a packet 
within a session (4 way handshake). How a client responds to this is 
undetermined... e.g. You don't know if the client starts the handshake 
over, or retransmits the last request. If you could sessionize the 
requests so that you only allowed so many hosts to perform a handshake 
you might be able to properly rate limit DHCP requests.

Different mechanisms for DHCP relay and DHCP snooping/limiting may 
either hurt or help this scenario. However, documentation is likely very 
vague and lacking in actual performance analysis details.

-Blake