From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping Date: Thu, 18 Feb 2021 17:40:09 -0500 Message-ID: <97AD5ACF-BEEF-4D31-BA6E-D5DA3BF73D20@rymes.net> In-Reply-To: <52e26906-7210-325f-5819-51777bf9a95e@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1358158556077282590==" List-Id: --===============1358158556077282590== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 18, 2021, at 12:08 PM, Adolf Belka (ipfire-dev) wrote: >=20 > =EF=BB=BFHi All, >=20 >> On 18/02/2021 17:05, Tom Rymes wrote: >>=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: >>>>> On 18/02/2021 14:06, Michael Tremer wrote: >>>>>=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. >>>> 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 >>> 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. >> [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 > I investigated this when I picked up this bug and I came to the same conclu= sion as Bernhard. >=20 > dhcpd has separate address pools so that users can have a range of dynamic = IP's that have tailored options for specific clients. >=20 > You can then have a specific address pool for a group of clients that for i= nstance have a short default lease time and specific ntp and dns server addre= sses etc. Another address pool can have a longer default lease time and diffe= rent ntp and dns servers etc >=20 > pfSense has implemented Additional Pools into its WUI and that could be som= ething that IPFire looks at later. If we have created already split pools wit= h no specified options then we have to decide how to deal with these when we = do move to additional pools. We are likely to run into the same problem as we= have now of being limited in what we do because the code has already been mo= dified in a different direction that could create problems for those existing= users, so we end up deciding that Additional Pools is too difficult to do be= cause it could disrupt existing users. They might not even know they have spl= it pools. Then we would have to figure out how to deal with split pools that = don't want to be seen as Additional Pools and with those that do. >=20 > If we stay as we are with a single pool then moving to Additional Pools at = some future time is not obstructed. With the current bug fix we will have war= nings for existing users that what they are doing has problems but it won't b= lock them from using their existing fixed leases that overlap with the dynami= c range. If they cannot change they at least know that they are doing somethi= ng wrong and could have problems. We don't create an obstruction that make fu= ture improvements difficult or impossible to implement. >=20 >=20 > Regards, >=20 > Adolf. >=20 Adolf, Isn=E2=80=99t the only way to make these multiple pools work to manually spec= ify which MAC addresses qualify for each pool? Doesn=E2=80=99t that make them= fixed leases? I think I=E2=80=99m missing a piece of this puzzle. Tom --===============1358158556077282590==--