From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Rymes <tom@rymes.net>
To: development@lists.ipfire.org
Subject: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping
Date: Thu, 18 Feb 2021 11:05:32 -0500
Message-ID: <E4AEBA51-0BEE-4A9B-BD5F-BFE57CAC1291@rymes.net>
In-Reply-To:
 <trinity-cde2a192-b73f-4dda-bbc8-de2a7d8dce15-1613662174069@3c-app-gmx-bap70>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4186530660654054582=="
List-Id: <development.lists.ipfire.org>

--===============4186530660654054582==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



> On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wr=
ote:
>=20
>> Gesendet: Donnerstag, 18. Februar 2021 um 16:18 Uhr
>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>>=20
>>>> On 18 Feb 2021, at 14:01, Adolf Belka (ipfire-dev) <adolf.belka(a)ipfire=
.org> wrote:
>>>=20
>>> On 18/02/2021 14:06, Michael Tremer wrote:
>>>=20

[snip]

>>> The only thing that would be more difficult is if the user expands an exi=
sting dynamic range that already overlaps with two fixed leases so that it no=
w overlaps with four fixed leases. It will be difficult to determine which we=
re the original existing and which are the new overlapped leases without havi=
ng a parameter stored in a file that counts which leases were overlapping whe=
n 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.
>>=20
>> Oh yeah, difficult question.
>>=20
>> I did not assume that this was very dynamic before.
>>=20
>> 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.1=
00-192.168.0.200, you would add a break for every static lease:
>>=20
>> * 192.168.0.100 - 192.168.0.105
>> * 192.168.0.107 - 192.168.0.112
>> * 192.168.0.114 - 192.168.0.200
>>=20
>> In this example, 192.168.0.106 and 192.168.0.113 would be static leases.
>>=20
>> That would make the solution transparent for the user, but a pain for the =
developer.
>>=20
>=20
> I do not think, that pools are right tool for the problem. Address pools ar=
e used with a slight different semantic in dhcpd. This difference may increas=
e 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 ope=
ned the big, it was my understanding that this was the proper way to handle t=
his. Others have arrived at a different conclusion, and to me it seems like m=
ore of a style thing than a functional thing.

Using multiple range definitions to exclude fixed addresses also has the bene=
fit of allowing a user to keep a host=E2=80=99s address the same, which can b=
e very helpful in instances where a lot of work may be required to change a h=
ost=E2=80=99s IP.

Tom

--===============4186530660654054582==--