From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Aw: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping Date: Thu, 18 Feb 2021 17:23:09 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6945140795180343885==" List-Id: --===============6945140795180343885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > Gesendet: Donnerstag, 18. Februar 2021 um 17:05 Uhr > Von: "Tom Rymes" > An: "Bernhard Bitsch" > Cc: development(a)lists.ipfire.org > Betreff: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping > >=20 >=20 > > On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch = wrote: > >=20 > >> Gesendet: Donnerstag, 18. Februar 2021 um 16:18 Uhr > >> Von: "Michael Tremer" > >>=20 > >>>> On 18 Feb 2021, at 14:01, Adolf Belka (ipfire-dev) 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 o= pened 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. >=20 > Using multiple range definitions to exclude fixed addresses also has the be= nefit of allowing a user to keep a host=E2=80=99s address the same, which can= be very helpful in instances where a lot of work may be required to change a= host=E2=80=99s IP. >=20 > 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 --===============6945140795180343885==--