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

[Bob Harold]

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?



-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk

On Fri, Jun 5, 2015 at 12:41 PM, dave c <dhcp at gvtc.drakkar.org> 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 <sean at mvtel.com> 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
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
> --
> Dave Calafrancesco
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150605/52dab638/attachment.html>