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: dont-use-fsync real world impact (sth...@nethelp.no)
2. Re: Override dynamic lease with static reservation (Marc Haber)
3. Re: dont-use-fsync real world impact (Jure Sah)
4. Re: Override dynamic lease with static reservation
(Christian Kratzer)
5. Re: DHCP restart with bulk lease data (Surya Teja)
6. Re: DHCP restart with bulk lease data (sth...@nethelp.no)
----------------------------------------------------------------------
Message: 1
Date: Sat, 28 Sep 2019 15:48:47 +0200 (CEST)
From: sth...@nethelp.no
To: dhcp-users@lists.isc.org, e...@juresah.si
Subject: Re: dont-use-fsync real world impact
Message-ID: <20190928.154847.333969999.sth...@nethelp.no>
Content-Type: Text/Plain; charset=us-ascii
> What changes would be required for this to work? A memory pool of
> offered IP addresses which are not to be assigned to new clients?
> Rotating a pool of physical disks to store leases in? Multiple
> synchronised DHCP servers?
>
> I am just trying to find a solution to this problem that is infinitely
> scalable.
But in practice you don't need infinite scalability, because you don't
have an infinite number of customers.
It's reasonably simple to scale up by using fast storage (battery backed
RAID with a suitable amount of memory is common), more servers and more
locations. Of course it has a cost - but so does your (or my) time.
Where do you want to spend your money?
Steinar Haug, Nethelp consulting, sth...@nethelp.no
------------------------------
Message: 2
Date: Sat, 28 Sep 2019 17:27:53 +0200
From: Marc Haber <mh+dhcp-us...@zugschlus.de>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Override dynamic lease with static reservation
Message-ID: <20190928152753.gy13...@torres.zugschlus.de>
Content-Type: text/plain; charset=utf-8
On Fri, Sep 27, 2019 at 06:59:51PM +0100, Simon Hobson wrote:
> Marc Haber <mh+dhcp-us...@zugschlus.de> wrote:
> > I find it a rather common occurence that a client that currently holds a
> > dynamic lease should get a static reservation of a different IP address.
> > Thus, a host entry is put into the configuration and the client
> > rebooted.
> >
> > It then asks for the last IP address it knows of, which is the dynamic
> > address. The server proceeds to look in its database, says "yup, here is
> > the address".
>
> Yes, that's correct.
> As an alternative to the host declaration, setting the reserved flag on the
> lease will achieve almost the same effect - but still needs OMSHELL or lease
> file editing). The address is permanently reserved for the client, but unlike
> a host declaration, it goes through the normal lease lifecycle (it can
> expire, DNS updates happen properly, etc).
What would be the omshell procedure for that?
I guess that a reservation is the best thing for infrastructure like
servers while a "reserved" lease is better for a client that should have
always the same IP address?
Or why are there two ways to do this?
> > Is there a configuration option to tell the server "if there is
> > something static for this client, forget everything dynamic you might
> > have and NAK the dynami address from the client"?
>
> deny known-clients (or allow unknown-clients) might do what you want.
I have set deny known-clients on my pool and at least my notebook
changed its IP address at the next (manually triggered) renew. I haven't
done more explicit tests, but this seems to have solved it. We'll see in
a week whether clients without a host statement drop off the net.
Thanks for helping!
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
------------------------------
Message: 3
Date: Sat, 28 Sep 2019 21:28:37 +0200
From: Jure Sah <e...@juresah.si>
To: dhcp-users@lists.isc.org
Subject: Re: dont-use-fsync real world impact
Message-ID: <a15f0f63-92be-668a-8137-7286a6e32...@juresah.si>
Content-Type: text/plain; charset=iso-8859-2
On 28. 09. 19 15:48, sth...@nethelp.no wrote:
>> What changes would be required for this to work? A memory pool of
>> offered IP addresses which are not to be assigned to new clients?
>> Rotating a pool of physical disks to store leases in? Multiple
>> synchronised DHCP servers?
>>
>> I am just trying to find a solution to this problem that is infinitely
>> scalable.
> But in practice you don't need infinite scalability, because you don't
> have an infinite number of customers.
>
> It's reasonably simple to scale up by using fast storage (battery backed
> RAID with a suitable amount of memory is common), more servers and more
> locations. Of course it has a cost - but so does your (or my) time.
> Where do you want to spend your money?
Well I quite disagree, even with SSD RAID arrays, the ultimate
performance is finite, whereas demands on a DHCP service for instance by
mobile clients is quite significant and it's easy to have too many
customers for a single server.
LP,
Jure
------------------------------
Message: 4
Date: Sun, 29 Sep 2019 10:04:10 +0200 (CEST)
From: Christian Kratzer <ck-li...@cksoft.de>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Override dynamic lease with static reservation
Message-ID: <alpine.bsf.2.21.9999.1909290955590....@nocfra1.cksoft.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hi,
On Fri, 27 Sep 2019, Marc Haber wrote:
> On Fri, Sep 27, 2019 at 04:39:31PM +0200, Christian Kratzer wrote:
>> my experience with isc dhcp is that once you have a host reservation
>> that matches the client, the host reservation takes precedence over
>> any historic lease.
>>
>> This should automatically lead to the server sending a NAK to a client
>> requesting the old dynamic lease.
>
> Negative, Sir. Not here.
your system is messed up in some way. I just verified the behaviour in my setup
- Redundant ISC dhcp setup running on two FreeBSD 12 VM
- isc-dhcp43-server-4.3.6P1_1
- Debian buster client vm
1. Allow debian buster vm to aquire dynamic lease
Sep 29 09:53:13 nocfra2 dhcpd[51637]: DHCPDISCOVER from 52:54:00:e4:f0:e6 via
192.168.37.1
Sep 29 09:53:14 nocfra2 dhcpd[51637]: DHCPOFFER on 192.168.37.212 to
52:54:00:e4:f0:e6 (buster) via 192.168.37.1
Sep 29 09:53:14 nocfra2 dhcpd[51637]: DHCPREQUEST for 192.168.37.212
(192.168.33.22) from 52:54:00:e4:f0:e6 (buster) via 192.168.37.1
Sep 29 09:53:14 nocfra2 dhcpd[51637]: DHCPACK on 192.168.37.212 to
52:54:00:e4:f0:e6 (buster) via 192.168.37.1
2. add host entry into both dhcp configs
host buster {
hardware ethernet 52:54:00:e4:f0:e6;
option host-name "buster";
fixed-address 192.168.37.63;
}
3. forcibly power off debian buster vm off using virsh
4. reboot debian buster vm
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPREQUEST for 192.168.37.212 from
52:54:00:e4:f0:e6 via 192.168.37.1: lease 192.168.37.212 unavailable.
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPNAK on 192.168.37.212 to
52:54:00:e4:f0:e6 via 192.168.37.1
Sep 29 09:55:19 nocfra2 dhcpd[51735]: uid lease 192.168.37.212 for client
52:54:00:e4:f0:e6 is duplicate on 192.168.37.0/24
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPDISCOVER from 52:54:00:e4:f0:e6 via
192.168.37.1
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPOFFER on 192.168.37.63 to
52:54:00:e4:f0:e6 via 192.168.37.1
Sep 29 09:55:19 nocfra2 dhcpd[51735]: uid lease 192.168.37.212 for client
52:54:00:e4:f0:e6 is duplicate on 192.168.37.0/24
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPREQUEST for 192.168.37.63
(192.168.33.21) from 52:54:00:e4:f0:e6 via 192.168.37.1
Sep 29 09:55:19 nocfra2 dhcpd[51735]: DHCPACK on 192.168.37.63 to
52:54:00:e4:f0:e6 via 192.168.37.1
as you see the vm tries to request the old dynamic ip but received a DHCPNAK
It subsequently falls back into DISOCOVER and gets the host entry.
Summary:
This is default isc dhcp behaviour.
>From all that I remember from looking at the code host always takes precence
>from dynamic leases.
So if this is not happening in your system then you are either
- doing something differently
- have some strange configuration or patches
- your host entry is not matching
So perhaps you would like to share your configuration and what version of isc
dhcp with what patches you are running.
Specifically it would be interesting to see how exactly you are doing your host
reservation.
Greetings
Christian
>> If it is not sending a nack then I would think that your host
>> reservation is not matching the client request. Subnet mismatch or
>> criteria mismatch.
>
> Then the reservation would not work after manually removing the dynamic
> lease from the database.
>
>> So you can just leave the lease to expire normally.
>
> On my systems, the dynamic lease gets renewed. And renewed. And renewed.
>
> Greetings
> Marc
>
>
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
------------------------------
Message: 5
Date: Sun, 29 Sep 2019 15:37:37 +0530
From: Surya Teja <suryateja...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP restart with bulk lease data
Message-ID:
<ca+0ac3ymhch9+k2ienvq4tf6rnpkmeuio1o_dq++2pcks7c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If you mean, does the server stop serving clients while it's doing this,
AFAIK it continues as normal. --->
Yes Simon, I mean this scenario Thanks for that clarification
Looking at the above, are you running failover ? If so, then I suspect one
of the records is from the partner server making an offer to a client at
the same time as this server does.---->
Yes I am running failover. but when the entry is shared from the failover
generally the binding state will be like *backup* right? but here in my
case i see both the entries as
*binding state active;* thus I got a doubt about this duplicate.
On Fri, Sep 27, 2019 at 10:51 PM Simon Hobson <dh...@thehobsons.co.uk>
wrote:
> Surya Teja <suryateja...@gmail.com> wrote:
> >
> > Hi Simon Thanks for reply,
> > Periodically, default is every hour, the server will write out a fresh
> leases file from it's internal structures --->
> > I have a doubt when the server write out a fresh leases file from it's
> internal structures will the dhcpd service be in off state at this duration?
>
> The question is a little ambiguous.
> If you mean, will this happen while the server is stopped, no it won't.
> If you mean, does the server stop serving clients while it's doing this,
> AFAIK it continues as normal.
>
> >> this file will contain no duplicate entries --->
> > Hi I have seen the duplicate entry in my server lease file
> > sample snippet:
> > ==============
> > lease 192.168.2.52 {
> > starts 5 2019/09/27 07:21:32;
> > ends 5 2019/09/27 08:21:32;
> > tstp 5 2019/09/27 08:51:32;
> > tsfp 5 2019/09/27 08:21:32;
> > cltt 5 2019/09/27 07:21:32;
> > binding state active;
> > next binding state expired;
> > hardware ethernet 70:bb:e9:37:d9:9e;
> > uid "\001p\273\3517\331\236";
> > set vendor-class-identifier = "android-dhcp-9";
> > client-hostname "RedmiNote6Pro";
> > }
> > lease 192.168.2.52 {
> > starts 5 2019/09/27 07:21:32;
> > ends 5 2019/09/27 08:21:32;
> > tstp 5 2019/09/27 08:51:32;
> > tsfp 5 2019/09/27 08:51:32;
> > atsfp 5 2019/09/27 08:51:32;
> > cltt 5 2019/09/27 07:21:32;
> > binding state active;
> > next binding state expired;
> > hardware ethernet 70:bb:e9:37:d9:9e;
> > uid "\001p\273\3517\331\236";
> > set vendor-class-identifier = "android-dhcp-9";
> > client-hostname "RedmiNote6Pro";
> > }
> > Yes It has same data, I don't see any issue on client side but want to
> make sure that, Is this acceptable in lease file ?
>
> The lease file will be clean **immediately** after it's been re-written.
> Once clients are served, then new records will be appended and there is
> likely to be more than one record for some clients.
> Looking at the above, are you running failover ? If so, then I suspect one
> of the records is from the partner server making an offer to a client at
> the same time as this server does.
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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/20190929/59188aff/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 29 Sep 2019 12:41:02 +0200 (CEST)
From: sth...@nethelp.no
To: dhcp-users@lists.isc.org, suryateja...@gmail.com
Subject: Re: DHCP restart with bulk lease data
Message-ID: <20190929.124102.273321115.sth...@nethelp.no>
Content-Type: Text/Plain; charset=us-ascii
> Yes I am running failover. but when the entry is shared from the failover
> generally the binding state will be like *backup* right? but here in my
> case i see both the entries as
> *binding state active;* thus I got a doubt about this duplicate.
If a DHCP binding is active, in a failover configuration, you should
expect to see it as active on *both* servers.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
------------------------------
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 131, Issue 25
*******************************************
