Re: randomly(!) assign ip's from dynamic address range

Posted by Bob Harold on Jun 05, 2015; 4:25pm
URL: http://isc-dhcp-users.193.s1.nabble.com/randomly-assign-ip-s-from-dynamic-address-range-tp156p169.html

Interesting idea to remove expired lease information form the server.   But I think that clients also remember their IP and request it the next time they connect.  Is that true?

On Fri, Jun 5, 2015 at 12:41 PM, dave c <[hidden email]> wrote:

However, there is a cleaner way to turn on pools in the system. You can use a cron job to add a deny all clients; statement to one of the 10 pools (as suggested below) or to one of the two pools as suggested by the prior responder. Then you aren't yanking the active leases away from active users.

But, an interesting side effect will be that when the pool is made available again, customers who previously had an IP will receive that original IP address if it's still available, which seems to not be what the customers of the OP was asking for.

So instead, the only way I can see to do it is to stop dhcpd services, which forces the leases file to be written from memory to disk as part of the shutdown, then use a script to remove all expired lease info from the dhcpd.leases file.

This will force the system to not know about the prior lease allocation that has since expired, removing the RFC required feature that says we must give back a prior IP address if it's available.

This is the only way I can think of to 'randomize' the IP given to previously expired customers.

But, like many have intimated, it's really working well against the purposes of the DHCP RFC which seems to be: "Be consistent & Don't break people's stuff."

Dave

On 6/5/15 11:32, Simon Hobson wrote:

Sean McMurray <[hidden email]> wrote:

You could maintain two config files with pools that do not overlap but are within the same
subnet. Then you could cron a dhcpd restart that alternates the config files every 24
hours.

That will do it - but it also means that clients will change address mid-session - breaking
any existing connections. For all the reasons that get listed when the usual variation of
this question comes up, that's a recipe for "unhappy customers".

On a more granular level (ie requiring less than double the required number of addresses),
you could do it with several pools and have (say) 9 out of 10 pools active at any time - that
would just need 11% extra addresses. It would still have the issue of killing active sessions
when a client has it's address pulled from under it.

_______________________________________________ dhcp-users mailing list
[hidden email] https://lists.isc.org/mailman/listinfo/dhcp-users

--
Dave Calafrancesco

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users