From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Adolf Belka (ipfire)" To: development@lists.ipfire.org Subject: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping Date: Fri, 19 Feb 2021 12:37:50 +0100 Message-ID: <56f72c03-bf1a-f40b-ff0c-5d3bb0618140@ipfire.org> In-Reply-To: <97AD5ACF-BEEF-4D31-BA6E-D5DA3BF73D20@rymes.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1836630903023147964==" List-Id: --===============1836630903023147964== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tom, On 18/02/2021 23:40, Tom Rymes wrote: >=20 >=20 >> On Feb 18, 2021, at 12:08 PM, Adolf Belka (ipfire-dev) wrote: >> >> =EF=BB=BFHi All, >> >>> On 18/02/2021 17:05, Tom Rymes wrote: >>> >>>>> On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch wrote: >>>> >>>>> Gesendet: Donnerstag, 18. Februar 2021 um 16:18 Uhr >>>>> Von: "Michael Tremer" >>>>> >>>>>>> On 18 Feb 2021, at 14:01, Adolf Belka (ipfire-dev) 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 h= aving 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 t= he simplest will be that any overlap due to a change in the dynamic range sho= uld 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 backe= nd 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 t= he 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 incr= ease 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 hand= le this. Others have arrived at a different conclusion, and to me it seems li= ke 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=E2=80=99s address the same, which c= an be very helpful in instances where a lot of work may be required to change= a host=E2=80=99s IP. >>> >>> Tom >> >> I investigated this when I picked up this bug and I came to the same concl= usion as Bernhard. >> >> dhcpd has separate address pools so that users can have a range of dynamic= IP's that have tailored options for specific clients. >> >> You can then have a specific address pool for a group of clients that for = instance have a short default lease time and specific ntp and dns server addr= esses etc. Another address pool can have a longer default lease time and diff= erent ntp and dns servers etc >> >> pfSense has implemented Additional Pools into its WUI and that could be so= mething that IPFire looks at later. If we have created already split pools wi= th 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 w= e have now of being limited in what we do because the code has already been m= odified in a different direction that could create problems for those existin= g users, so we end up deciding that Additional Pools is too difficult to do b= ecause it could disrupt existing users. They might not even know they have sp= lit 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. >> >> 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 wa= rnings for existing users that what they . That pool then covers are doing ha= s problems but it won't block them from using their existing fixed leases tha= t overlap with the dynamic range. If they cannot change they at least know th= at they are doing something wrong and could have problems. We don't create an= obstruction that make future improvements difficult or impossible to impleme= nt. >> >> >> Regards, >> >> Adolf. >> >=20 > Adolf, >=20 > Isn=E2=80=99t the only way to make these multiple pools work to manually sp= ecify which MAC addresses qualify for each pool? Doesn=E2=80=99t that make th= em fixed leases? For one pool you have allow unknown-clients. That pool then acts like the nor= mal dynamic allocation of IPs. The second pool you have deny unknown-clients. This then allows clients with = host declarations that don't have fixed IP addresses defined to get dynamic I= Ps from a different range. Then you still have the host declarations where you define the IP address whi= ch are then like the traditional IPFire Fixed Leases. The second pool does require mac addresses to be defined but not IP addresses= . Currently IPFire only has host declarations with both mac address and IP ad= dress. So you then have unknown clients getting one dynamic IP range, known clients = that don't have IPs preset getting another dynamic IP range and known clients= with defined IPs getting those IPs. You can then have settings like DNS serv= er, nip server, default lease time etc defined differently at a global level = and for each address pool. Another way is to create a class based on the option host-name if the client = has been set up to send it. You can select all those clients that have part o= f their host-name defined in a certain way. i.e. you have clients that are na= med foobar-xyz then you can create a class for all clients that have a hostna= me starting with foobar. Then you can create a pool that only applies to memb= ers of that class. None of the above can be done currently with the WUI but would be possible wi= th dhcpd if someone wanted to implement it into the WUI. Regards, Adolf. >=20 > I think I=E2=80=99m missing a piece of this puzzle. >=20 > Tom >=20 --===============1836630903023147964==--