From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping Date: Fri, 19 Feb 2021 18:57:00 +0000 Message-ID: <2ADA7D9D-E567-48E5-B77E-6047BA988836@ipfire.org> In-Reply-To: <56f72c03-bf1a-f40b-ff0c-5d3bb0618140@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1392695324703426241==" List-Id: --===============1392695324703426241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Great discussion everyone. I guess we have two problems on our hand: 1) How do we do this right? 2) How do we make it compatible with the current UI? Rewriting the whole UI is a big thing and changing anything *will* break peop= le=E2=80=99s networks. That is something we cannot do. In IPFire 3, I added the option to add multiple pools and in those add multip= le ranges of IP addresses that can be assigned. Maybe those who understood ho= w this is supposed to work can review this and tell me if this was a good ide= a, or if I got it wrong: https://git.ipfire.org/?p=3Dnetwork.git;a=3Dblob;f=3Dsrc/functions/function= s.dhcpd;h=3D3b1214fb937d0efd8ea8c3a4d4113f13bc3b5d52;hb=3DHEAD Maybe we can use this as a study for question 1) because we do not need to ca= re about compatibility. Secondly, we need to look at IPFire 2 and *if* this can be done right without= breaking anything. -Michael > On 19 Feb 2021, at 11:37, Adolf Belka (ipfire) w= rote: >=20 > Hi Tom, >=20 > On 18/02/2021 23:40, Tom Rymes wrote: >>> 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= existing dynamic range that already overlaps with two fixed leases so that i= t now overlaps with four fixed leases. It will be difficult to determine whic= h were the original existing and which are the new overlapped leases without = having 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 = the simplest will be that any overlap due to a change in the dynamic range sh= ould 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 back= end 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 lease= s. >>>>>>=20 >>>>>> That would make the solution transparent for the user, but a pain for = the developer. >>>>>>=20 >>>>> I do not think, that pools are right tool for the problem. Address pool= s are used with a slight different semantic in dhcpd. This difference may inc= rease in future. >>>>> Not mentioning the effort to split the set of possible IP addresses and= to 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 han= dle this. Others have arrived at a different conclusion, and to me it seems l= ike more of a style thing than a functional thing. >>>>=20 >>>> 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 = can be very helpful in instances where a lot of work may be required to chang= e a host=E2=80=99s IP. >>>>=20 >>>> Tom >>>=20 >>> I investigated this when I picked up this bug and I came to the same conc= lusion as Bernhard. >>>=20 >>> dhcpd has separate address pools so that users can have a range of dynami= c 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= instance have a short default lease time and specific ntp and dns server add= resses etc. Another address pool can have a longer default lease time and dif= ferent ntp and dns servers etc >>>=20 >>> pfSense has implemented Additional Pools into its WUI and that could be s= omething that IPFire looks at later. If we have created already split pools w= ith no specified options then we have to decide how to deal with these when w= e 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 = modified in a different direction that could create problems for those existi= ng users, so we end up deciding that Additional Pools is too difficult to do = because it could disrupt existing users. They might not even know they have s= plit pools. Then we would have to figure out how to deal with split pools tha= t 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 a= t some future time is not obstructed. With the current bug fix we will have w= arnings for existing users that what they . That pool then covers are doing h= as problems but it won't block them from using their existing fixed leases th= at overlap with the dynamic range. If they cannot change they at least know t= hat they are doing something wrong and could have problems. We don't create a= n obstruction that make future improvements difficult or impossible to implem= ent. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >> Adolf, >> Isn=E2=80=99t the only way to make these multiple pools work to manually s= pecify which MAC addresses qualify for each pool? Doesn=E2=80=99t that make t= hem fixed leases? >=20 > For one pool you have allow unknown-clients. That pool then acts like the n= ormal dynamic allocation of IPs. > The second pool you have deny unknown-clients. This then allows clients wit= h host declarations that don't have fixed IP addresses defined to get dynamic= IPs from a different range. > Then you still have the host declarations where you define the IP address w= hich are then like the traditional IPFire Fixed Leases. >=20 > The second pool does require mac addresses to be defined but not IP address= es. Currently IPFire only has host declarations with both mac address and IP = address. >=20 > So you then have unknown clients getting one dynamic IP range, known client= s that don't have IPs preset getting another dynamic IP range and known clien= ts with defined IPs getting those IPs. You can then have settings like DNS se= rver, nip server, default lease time etc defined differently at a global leve= l and for each address pool. >=20 >=20 > Another way is to create a class based on the option host-name if the clien= t has been set up to send it. You can select all those clients that have part= of their host-name defined in a certain way. i.e. you have clients that are = named foobar-xyz then you can create a class for all clients that have a host= name starting with foobar. Then you can create a pool that only applies to me= mbers of that class. >=20 >=20 > None of the above can be done currently with the WUI but would be possible = with dhcpd if someone wanted to implement it into the WUI. >=20 > Regards, >=20 > Adolf. >=20 >> I think I=E2=80=99m missing a piece of this puzzle. >> Tom --===============1392695324703426241==--