[Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host

Oliver Freyermuth o.freyermuth at googlemail.com
Sun Jan 26 19:01:22 GMT 2020


Am 07.01.20 um 22:51 schrieb Simon Kelley:
> On 23/12/2019 11:24, Harald Jensas wrote:
>> Hi,
>>
>> The patch below is a slight alteration to a possible solution
>> discussed in http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html.
>>
>> My approach here does not require making dhcp-host conditional on a
>> tag. However, making dhcp-host conditional on a tag would be a nice
>> addition that could be introduced as a follow up to this to have a
>> match on the tag of the final OS to keep the provisioned system
>> consistently configured with a specific address can be very handy. For
>> the Openstack use-case I am working in, this however is'nt necessary.
>>
>> I have confirmed that the patch below together with a small change in
>> Openstack Ironic (see: https://review.opendev.org/700002) solved the
>> long standing issue when doing network booting and node provisioning
>> in combination with static only dhcp configuration.
>>
>> We are looking forward to comments and feedback regarding this approach.
>>
>> Thank you!
>>
> 
> If I've understood correctly, this looks like it might be a viable
> solution. Question: how many addresses do you configure for each host,
> and is this fragile if the boot process changes, for instance to add new
> steps? Could we add new syntax to dhcp-host which allows it to configure
> a range of addresses, rather than having a number of dhcp-host entries
> for each stage of the boot process? That would be a bigger change, but
> might be a neater solution?
> 
> I guess that the final adddress that the host ends up with depends on
> the number of addresses allocated by other parts of the boot process,
> but as the DNS entry ends up pointing to that final address (does it? -
> need to check this) that's not a problem.

I also like this new approach. "Wasting" 4 addresses for one host seems to be the only way
to solve this while conforming to RFCs. 

However, there's one issue I can't find a good solution for in this scheme - 
how to solve the "DNS problem" if dnsmasq is only used for DHCP, but DNS is provided by other means? 

The "range reservation", as highlighted, means the final address is not well predictable (may depend on hardware,
other parts of the boot process etc.). 
When dnsmasq is also doing the DNS part, that's not a problem, since it will use the final / "most recently leased" address for DNS. 
Does anybody have a good proposal for the case when DHCP is provided by dnsmasq but DNS is maintained separately
(i.e. the "final address" needs to be fixed)? 

Cheers,
	Oliver

> 
> Simon.
> 
> 
> 
> 
> Simon.
> 
> 
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



More information about the Dnsmasq-discuss mailing list