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 17:38:08 -0500
Message-ID: <BA28C7EA-E95D-49EF-8A4A-1E36995628FA@rymes.net>
In-Reply-To:
 <trinity-a5882d2e-88b6-4337-bb53-c7b3063dd0aa-1613665389282@3c-app-gmx-bap70>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4111570087007066259=="
List-Id: <development.lists.ipfire.org>

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


> On Feb 18, 2021, at 11:23 AM, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wr=
ote:
>=20
> =EF=BB=BFHi,
>=20
>=20
>> 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 overlappi=
ng
>>=20
>>=20
>>=20
>>>> On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de>=
 wrote:
>>>=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)ipfi=
re.org> wrote:
>>>>>=20
>>>>> On 18/02/2021 14:06, Michael Tremer wrote:
>>>>>=20
>>=20
>> [snip]
>>=20
>>>>> The only thing that would be more difficult is if the user expands an e=
xisting 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 ha=
ving a parameter stored in a file that counts which leases were overlapping w=
hen the Core Update upgrade is carried out. That could be done but I think th=
e simplest will be that any overlap due to a change in the dynamic range shou=
ld 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 backen=
d 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:
>>>>=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 th=
e developer.
>>>>=20
>>>=20
>>> 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 incre=
ase in future.
>>> Not mentioning the effort to split the set of possible IP addresses and t=
o verify this process.
>>=20
>> [snip]
>>=20
>> 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 handl=
e this. Others have arrived at a different conclusion, and to me it seems lik=
e more of a style thing than a functional thing.
>>=20
>> Using multiple range definitions to exclude fixed addresses also has the b=
enefit of allowing a user to keep a host=E2=80=99s address the same, which ca=
n be very helpful in instances where a lot of work may be required to change =
a host=E2=80=99s IP.
>>=20
>> Tom
>=20
> 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.
>=20
> 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. Ye=
ars pass. I inherit this network and I have to move the IP out of the dynamic=
 range, but I=E2=80=99m going to have to maniacally change various clients, e=
tc.

It=E2=80=99s not the end of the world, but the currently proposed strategy re=
quires me to move that IP, whereas the option of multiple range definitions p=
er subnet ( excluding the reserved addresses) allows me to keep it for now an=
d move it when. I  able to properly plan to do so.

Tom

--===============4111570087007066259==--