Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Strange DHCP behaviour (Bob Harold)
2. Re: Strange DHCP behaviour (Simon Hobson)
3. Re: ISC dhcpd 4.4.1 dhcpd.leases file size and entries age
(Niall O'Reilly)
4. Re: Strange DHCP behaviour (tony)
5. Re: Strange DHCP behaviour (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Oct 2018 14:51:40 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Strange DHCP behaviour
Message-ID:
<ca+nkc8avbka5vv4qdm7bnznmiojwad-g3ksoj_5oss9hewz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Oct 24, 2018 at 7:15 AM tony <li...@vanderhoff.org> wrote:
> Hi,
> I'm running a DHCP server (4.3) under Debian Stretch to serve a small
> local domain. It behaves well for most clients, but I have a laptop
> (also Debian Stretch) for which I wish to assign a fixed address. My
> server configuration is this (tony-lt being the laptop):
> ------------------------------------------------------------------
> # The ddns-updates-style parameter controls whether or not the server will
> # attempt to do a DNS update when a lease is confirmed. We default to the
> # behavior of the version 2 packages ('none', since DHCP v2 didn't
> # have support for DDNS.)
> ddns-update-style none;
>
> # option definitions common to all supported networks...
> #option domain-name "example.org";
> option domain-name "chalet.vanderhoff.org";
> #option domain-name-servers ns1.example.org, ns2.example.org;
> option domain-name-servers 192.168.1.1;
>
> default-lease-time 600;
> max-lease-time 7200;
>
> # If this DHCP server is the official DHCP server for the local
> # network, the authoritative directive should be uncommented.
> authoritative;
>
> # Use this to send dhcp log messages to a different log file (you also
> # have to hack syslog.conf to complete the redirection).
> log-facility local7;
>
> # No service will be given on this subnet, but declaring it helps the
> # DHCP server to understand the network topology.
>
> #subnet 10.152.187.0 netmask 255.255.255.0 {
> #}
>
> # This is a very basic subnet declaration.
>
> subnet 192.168.1.0 netmask 255.255.255.0
> {
> range 192.168.1.200 192.168.1.254;
> option routers 192.168.1.10;
> }
>
> host tony-lt
> {
> hardware ethernet 0c:60:76:6c:e6:6f;
> fixed-address 192.168.1.199;
> }
> ------------------------------------------------------------------
>
> Despite this configuration I have failed to get that address for the
> laptop; it seems to be stuck on 192.168.1.254, currently. It may have
> legitimately had that address in the past.
>
> I have stopped and cleared the client via 'dhclient -r', deleted the
> files in /var/lib/dhclient, before restarting it with 'dhclient -v, It
> immediately requests ..254
>
> I'm seeing this in the server log:
> ------------------------------------------------------------------
> Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
> from 0c:60:76:6c:e6:6f (tony-lt) via eth0
> Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
> 0c:60:76:6c:e6:6f via eth0
> Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.244
> from f4:81:39:82:53:c4 via eth0
> Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPACK on 192.168.1.244 to
> f4:81:39:82:53:c4 via eth0
> Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
> from 0c:60:76:6c:e6:6f via eth0
> Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
> 0c:60:76:6c:e6:6f (tony-lt) via eth0
> Oct 24 12:52:41 router-pi dhcpd[1068]: reuse_lease: lease age 9 (secs)
> under 25% threshold, reply with unaltered, existing lease for 192.168.1.254
> Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
> from 0c:60:76:6c:e6:6f (tony-lt) via eth0
> Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
> 0c:60:76:6c:e6:6f (tony-lt) via eth0
> ------------------------------------------------------------------
>
> Apart from the rather frequent lease request, which I suspect is due to
> NetworkManager on this laptop, what is the 'reuse-lease' comment?
>
> Has anyone any suggestions on how to fix this, please?
>
> Cheers, Tony
>
In this situation I typically create a 'fake' host reservation for the old
IP with a dummy MAC address, which forces the DHCP server to refuse to give
out that address. Once the laptop gets the right IP, then the fake entry
can be removed.
--
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20181024/ca862888/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 24 Oct 2018 20:22:48 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Strange DHCP behaviour
Message-ID: <84a5eeb5-d094-42b9-9f57-a13a5096e...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
tony <li...@vanderhoff.org> wrote:
> Despite this configuration I have failed to get that address for the
> laptop; it seems to be stuck on 192.168.1.254, currently. It may have
> legitimately had that address in the past.
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.
------------------------------
Message: 3
Date: Wed, 24 Oct 2018 22:40:09 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: ISC dhcpd 4.4.1 dhcpd.leases file size and entries age
Message-ID: <fbb307c8-3c68-4f4a-a5c8-d80d31ead...@ucd.ie>
Content-Type: text/plain; charset="utf-8"
On 18 Oct 2018, at 19:08, Simon Hobson wrote:
> I believe that as soon as the address is re-used, it is no longer recorded as
> having belonged to the older lease.
I believe you?re mistaken, Simon, but I may be mistaken in this.
> If you think about it, that 4 year old device could come back, it's address
> might be free "now" - but then the newer device comes back and it can't have
> it's address back.
>
> In the general case, it makes sense to do it that way - when it comes to
> recycling addresses, the longer since it was last used, the less likely it is
> that the device will be coming back for it.
>
>
> For the benefit of the OP, the address allocation is done by :
> - If the device is already known* then it is given it's previous address
if currently available.
Either allocation to another device or change in pool definitions (range of
valid addresses, eligibility criteria) might make the address unavailable.
> - If there are any addresses which have never been used (no entry in leases
> database) then one of those is allocated
> - A previously used but expired lease is recycled on a least recently used
> basis
> - An address marked as abandoned is reclaimed
> - Allocation fails !
>
> * Clients are known by the Client-ID if one was provided, or by the MAC
> address if no Client-ID provided. A single device could appear as several
> different clients if it uses different Client-IDs,
Niall O?Reilly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20181024/912c0dea/attachment-0001.bin>
------------------------------
Message: 4
Date: Thu, 25 Oct 2018 10:56:10 +0200
From: tony <li...@vanderhoff.org>
To: dhcp-users@lists.isc.org
Subject: Re: Strange DHCP behaviour
Message-ID: <3fe5b15c-7c5d-9f4d-7f62-a8c9e653c...@vanderhoff.org>
Content-Type: text/plain; charset=utf-8
On 24/10/2018 21:22, Simon Hobson wrote:
> tony <li...@vanderhoff.org> wrote:
>
>> Despite this configuration I have failed to get that address for the
>> laptop; it seems to be stuck on 192.168.1.254, currently. It may have
>> legitimately had that address in the past.
>
> 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.
>
Thanks Simon, and Bob, for your very helpful replies.
Whilst waiting for a response to my cry for help, I continued fiddling,
and deleted the leases file. That seemed to fix thye problem.
Your fix would have been more elegant, maybe I should have waited ...
Thanks, anyway.
Cheers, tony.
------------------------------
Message: 5
Date: Thu, 25 Oct 2018 11:08:26 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Strange DHCP behaviour
Message-ID: <4f79fcc8-5faa-46f4-ba9f-aa3a1c1d0...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
tony <li...@vanderhoff.org> wrote:
> Whilst waiting for a response to my cry for help, I continued fiddling,
> and deleted the leases file. That seemed to fix thye problem.
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.
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 120, Issue 13
*******************************************
