On 29/06/17 06:37, Todd Sankey wrote:
> On our guest network we often have visitors that stay for a few days
> coming and going. We also have a few itinerant workers who show up every
> few weeks for a few days. Then there is the set of one-time visitors.
> The current mechanism of address assignment uses hashing of the hardware
> address to pick a starting point and then searching for an available
> address. This works fairly well, but in looking at the logs, hash
> collisions happen often enough that most recurring visitors have been
> assigned at least 2 different addresses and some have had 4 or more. 
> This is a problem for our firewall reporting. The firewall does some
> analytics by IP address trying to learn typical behaviour. It would be
> very helpful if there was a very high probability of being assigned the
> same address without having to setup static addresses.
> We could create a very large pool of dynamic addresses to reduce the
> chances of hash collisions. A /24 or smaller network has pretty high
> collision probability for a fairly small number of visitors so you are
> probably limited to a fairly big chunk of the 10. private network for
> this approach. Since we already have several 192.168.x networks, I
> looked at another approach. This was to use a least-recently-used
> address reuse policy. I developed a patch that does this. This involved
> a few steps.
> 1) Currently leases go from the "leases" list to the "old_leases" list
> when they expire. Once the script has processed them, they get deleted.
> The main change here was to add a "past_leases" list. After being on the
> "old_leases" list, they get put on a past_leases list which is
> maintained in order sorted by expiration time from oldest to newest.
> When adding an item to this list, it is inserted in order and all other
> entries for the same hardware ID are deleted.
> 2) Added some routines in leases.c for detecting if there is a past
> lease for a hardware ID and for finding the least-recently-used past lease.
> 3) Changed the routine for saving leases to the lease database file to
> include writing the old_leases and the past_leases lists. The reload
> logic didn't need to change at all. The expired leases get loaded and
> then pruned which pushes them back onto the "past_leases" 
> 4) In address_allocate, change the search strategy to use a past lease
> if one exists, otherwise find an address that has no past lease
> associated with it if one exists in the pool, otherwise use the address
> from the least recently used lease that is compatible with the network.
> 5) In the dhcp_reply handler when handling the DHCPDISCOVER message,
> check if there is a past lease for the incoming request and offer that
> if there is. Otherwise use address_allocate to find one.
> 6) In the dhcp_reply handler when handling the DHCPREQUEST message, if
> there is a past lease for the requested address for a different hardware
> address, deny the request forcing the caller to discover to get an address.
> 7) Added a command line option "--dhcp-remember-ip" to enable the behaviour.
> So, does this sound like a useful feature to include generally? Is there
> a better way to do it? It has helped our reporting immensely without
> adding any IT overhead of maintaining a static lease database. I am not
> sure if there are other use cases. If this has some interest I will
> flesh out our patch, which currently does not include DHCPv6 and offer
> it for inclusion.

My thoughts in no particular order:

1) You're basically making dnsmasq work like ISC dhcpd. Why not use ISC

2) ISC dhcpd is more efficient, because it doesn't write out the whole
lease database each time it changes, it just appends to the end of the
file. You risk ending up with a large list of past leases, and therefore
a lease database much larger that than the current set up clients, and
therefore a large file to write each time it changes.

3) There are implications if the lease database is stored externally
using the lease-change script.

4) This won't work if dnsmasq is built with HAVE_BROKEN_RTC, where the
expiry time of the lease is not stored, only its length.

5) Would it make sense to teach your firewall analytics to use the lease
database to track hosts, rather than IP addresses?

6) I'm not clear how this is easier than a 10.x.x.x network.

I guess that I'm not sure I want to take a patch which has a fairly
large impact for a case which is handled by using another DHCP server
and which moves dnsmasq away from the small footprint niche it's
designed for.



Attachment: signature.asc
Description: OpenPGP digital signature

Dnsmasq-discuss mailing list

Reply via email to