Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping

[Tom Rymes <tom@rymes.net>]

[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]


> On Feb 18, 2021, at 11:23 AM, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wrote:
> 
> Hi,
> 
> 
>> Gesendet: Donnerstag, 18. Februar 2021 um 17:05 Uhr
>> Von: "Tom Rymes" <tom(a)rymes.net>
>> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
>> Cc: development(a)lists.ipfire.org
>> Betreff: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping
>> 
>> 
>> 
>>>> On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wrote:
>>> 
>>>> Gesendet: Donnerstag, 18. Februar 2021 um 16:18 Uhr
>>>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>>>> 
>>>>>> On 18 Feb 2021, at 14:01, Adolf Belka (ipfire-dev) <adolf.belka(a)ipfire.org> wrote:
>>>>> 
>>>>> On 18/02/2021 14:06, Michael Tremer wrote:
>>>>> 
>> 
>> [snip]
>> 
>>>>> The only thing that would be more difficult is if the user expands an existing dynamic range that already overlaps with two fixed leases so that it now overlaps with four fixed leases. It will be difficult to determine which were the original existing and which are the new overlapped leases without having a parameter stored in a file that counts which leases were overlapping when the Core Update upgrade is carried out. That could be done but I think the simplest will be that any overlap due to a change in the dynamic range should just get a warning and not an error. Does that sound okay.
>>>> 
>>>> Oh yeah, difficult question.
>>>> 
>>>> I did not assume that this was very dynamic before.
>>>> 
>>>> Potentially it is a good solution to simply split the pool in the backend and not tell the user. So in the configuration instead of writing 192.168.0.100-192.168.0.200, you would add a break for every static lease:
>>>> 
>>>> * 192.168.0.100 - 192.168.0.105
>>>> * 192.168.0.107 - 192.168.0.112
>>>> * 192.168.0.114 - 192.168.0.200
>>>> 
>>>> In this example, 192.168.0.106 and 192.168.0.113 would be static leases.
>>>> 
>>>> That would make the solution transparent for the user, but a pain for the developer.
>>>> 
>>> 
>>> I do not think, that pools are right tool for the problem. Address pools are used with a slight different semantic in dhcpd. This difference may increase in future.
>>> Not mentioning the effort to split the set of possible IP addresses and to verify this process.
>> 
>> [snip]
>> 
>> This was my original suggestion for how to handle this, and at the time I opened the big, it was my understanding that this was the proper way to handle this. Others have arrived at a different conclusion, and to me it seems like more of a style thing than a functional thing.
>> 
>> Using multiple range definitions to exclude fixed addresses also has the benefit of allowing a user to keep a host’s address the same, which can be very helpful in instances where a lot of work may be required to change a host’s IP.
>> 
>> Tom
> 
> In instances where it is a big effort to change a host's IP, it is also the (same?) effort to set this IP. Therefore it is possible to define this IP as a fixed lease for this (known!) device.
> 
> Bernhard

Bernhard: not really. The way I see it is that someone sets up a server, then assigns it a reserved/fixed address that overlaps with the dynamic range. Years pass. I inherit this network and I have to move the IP out of the dynamic range, but I’m going to have to maniacally change various clients, etc.

It’s not the end of the world, but the currently proposed strategy requires me to move that IP, whereas the option of multiple range definitions per subnet ( excluding the reserved addresses) allows me to keep it for now and move it when. I  able to properly plan to do so.

Tom