Re: strange DHCP behaviour [SOLVED]
On 24/10/2018 14:41, tomas@tuxteam.de wrote:
> On Wed, Oct 24, 2018 at 02:35:37PM +0200, tony wrote:
>
> [...]
>
>> Ew, this time it worked. I wonder why deleting the leases file was
>> better than clearing it out?
>
> Some things you gotta delete *twice*.
>
> (Sigh. I guess everyone here knows _that_ feeling... :)
>
> Glad you found it
> -- t
>
I submitted my problem to the isc-dhcp mail list, but while waiting for
their reply, I deleted the leases file. They came back with some useful
advice, which I wish I had taken. I admitted to them what I had done.
I think it would be useful ro repeat their caution:
-------------------------------------------------------------------
For the benefit of others finding this thread ...
In general it is a very bad idea deleting the leases file. In your case,
not a problem as you have a small network and still at the testing stage.
But in general, with an active network, you have blown away the record
of all the "promises" the server has made to clients. There will be
clients with active leases, but the server will have no record of them.
At the very best, this can result in churn when clients come back (eg a
device that's been switched off is turned on) and their address has been
leased to another device - so they get a new address. But what is likely
to happen is new clients come along and get offered an address that's
already in use - what happens then depends on a number of factors.
If the device already using the address responds to pings, then the
server may detect it with it's "ping before offer" function. The address
will then be marked as abandoned - and not used again unless you
completely run out of free addresses. This results in increased address
churn "forever" as part of your pool is never used unless you clean it
up (or they get recovered if you run out of addresses which shouldn't
happen in a well provisioned network).
If the device doesn't respond to a ping, then the server will offer the
address to the client. The client *should* detect that it's already in
use and reject the offer - but the server will not stop offering the
address to clients, resulting in a lot of "offer-reject" exchanges. If
the client is poorly implemented and just accepts the address then you
now have two devices using the same address and neither will work
properly/at all. Users may or may not (depending on the implementation)
get a warning about the duplicate address.
-------------------------------------------------------------------
Ouch!
The correct solution (according to the experts) is:
-------------------------------------------------------------------
The client is obviously retaining state of the address it once had, and
is requesting that address. As the address is available for teh client,
it is given it. Some ways to fix it :
Remove the address from the range(s) allowed in the server config. Next
time the client requests the address, it will be refused (DHCP-Nack
message), the client will then be given it's fixed address.
Split out the address to separate range (in a separate pool) and add
"deny booting" to the range. As above, on the next renew the client will
be refused.
Add "deny known clients" to the range. The host statement makes the
laptop a known client, and so the deny known clients statement will mean
that the client is not allowed an address from the range. So as above,
next time the client sends a request, it will be refused.
Note that this would affect other hosts with a host statement.
Similar to above, define a class that matches the client and add "deny
members of <name of class>" to the range.
Stop the server and edit the leases file. Find the last lease entry for
the host and edit it - change the hardware and/or Client-ID fields so
that the lease now belongs to a different client. Then start the server
again. Next time the client sends a request, it will be denied as the
server now thinks that the address belongs to a different client.
The lease will eventually time out and go into the pot to be re-used. It
won't be reused until every address in the range(s) has already been
used at least once - "never used before" addresses are used before any
previously used address is re-used for a different client.
-------------------------------------------------------------------
Cheers, tony
Reply to: