[Dnsmasq-discuss] Bonding interactions with dnsmasq: ip address allocation

Simon Kelley simon at thekelleys.org.uk
Wed Mar 30 22:53:22 BST 2011


On 30/03/11 22:27, Paul Smith wrote:
> On Wed, 2011-03-30 at 21:07 +0100, Simon Kelley wrote:
>> A few weeks back, someone came up with a valid use-case for being able
>> to allocate IP addreses sequentially, and this looks like a second
>> one.
>
> Ooh.  Sweet.
>
> However, I have a question about this.  You may recall, Simon, that I
> was having serious issues because I had lots of systems booting/doing
> DHCP requests at the same time, and dnsmasq implemented a suboptimal
> hashing function to determine the initial starting IP, where lots of my
> systems were hashing to the same "bucket".  Then there was a ACK/NACK
> storm as dnsmasq was handing out duplicate IP addresses to lots of
> different clients and they would go through this handshake procedure.
>
> I'm a bit concerned with the sequential allocation model that I'll get
> back into that.  If 5 clients all boot at the same time, will they all
> be handed the same IP address for the initial response?  Or, is the
> implementation of the sequential allocation model such that this won't
> be a problem?
>
>
> I know I didn't explain the above very well.  If you need more detail to
> know what in the heck I'm talking about just let me know :-).

Perfectly clear to me.

I fear that this may be a problem. The sequential model is implemented 
as "one greater than the largest address currently leased" so lots of 
machines hitting a network at the same time would all be offered the 
same address. The alternative is to just keep a counter which gets 
incremented with each DHCPOFFER, but that has the disadvantage that a 
client which repeats a DHCPDISCOVER will never get offered the same 
address twice. This is known to confuse clients.

Maybe the sequential model will work for networks with a few machines, 
and the hashed one for larger networks?

Simon.




More information about the Dnsmasq-discuss mailing list