[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