[Already SOLVED] Precious leases?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Already SOLVED] Precious leases?

Nicolas Ecarnot
Hello,

This message deals with NO PROBLEM, nothing wrong, nor issue to solve.

It is just a discussion about something I don't get.
I'm using DHCP since more than a decade in very complex failover setups,
I'm using numerous script-generated hundreds of page dhcpd.conf servers
amongst hundreds of synced sites.
All this is working flawlessly.

Though, I've never understood in what cases it should be important to
keep safely the dhcp lease files. I mean, for dynamic leases hosts, they
just will have to issue new queries - this won't load the servers as all
those hosts lease time has been randomly spread in date and time, so
their queries won't burst all in the same time.
And for the fixed lease, there is neither a hurry to get a reply because
if the dhcp infrastructure replies lately, the dhcp implementation
allows late query retries in time.

So, I don't see anything horrible happening if I loose all my leases
files and restart my servers...?

--
Nicolas ECARNOT
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: [Already SOLVED] Precious leases?

Eugene Grosbein
10.12.2017 19:08, Nicolas Ecarnot wrote:

> Hello,
>
> This message deals with NO PROBLEM, nothing wrong, nor issue to solve.
>
> It is just a discussion about something I don't get.
> I'm using DHCP since more than a decade in very complex failover setups, I'm using numerous script-generated hundreds of page dhcpd.conf servers amongst hundreds of synced sites.
> All this is working flawlessly.
>
> Though, I've never understood in what cases it should be important to keep safely the dhcp lease files. I mean, for dynamic leases hosts, they just will have to issue new queries - this won't load the servers as all those hosts lease time has been randomly spread in date and time, so their queries won't burst all in the same time.
> And for the fixed lease, there is neither a hurry to get a reply because if the dhcp infrastructure replies lately, the dhcp implementation allows late query retries in time.
>
> So, I don't see anything horrible happening if I loose all my leases files and restart my servers...?

When DHCP client tries to extend its lease time period, a server can agree and just extend the time
or it can insist on new address. In the latter case, all client's currently established long-lived
connections will break. Also, HTTP auth cookies may be bounded to the (public) IP address and they break too.

With DHCP server lease files in place, your DHCP clients get much more stable and seamless workflow
because without them, the server have no information of previous MAC/IP connections to offer same IP.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: [Already SOLVED] Precious leases?

Simon Hobson
In reply to this post by Nicolas Ecarnot
Nicolas Ecarnot <[hidden email]> wrote:

> Though, I've never understood in what cases it should be important to keep safely the dhcp lease files. I mean, for dynamic leases hosts, they just will have to issue new queries - this won't load the servers as all those hosts lease time has been randomly spread in date and time, so their queries won't burst all in the same time.
...
> So, I don't see anything horrible happening if I loose all my leases files and restart my servers...?

OK, lets assume you have a range of clients on the network, of various types. You now for whatever reason blow away the leases file, lets look at the things that can happen.

First we'll look at the cases you are thinking of.
A client (with dynamic address) that's on the network and active will eventually ask to renew it's lease - and provided the address is still free (see later) it will be given it. Eventually each client will get a fresh lease and the servers will be up to date.
Clients where you've given it a fixed address will, as you point out, be no problem.

Now, what else can happen ?
For some time you have a situation where your server has made promises to clients, but has no knowledge of what they were.
Suppose a client starts up/connects that does not have a valid lease. It asks the server for a lease, the server looks in it's tables and finds that it's got "lots" of "free" addresses - it picks one and then one of two things happen :

1) It does a "ping before offer", gets a reply, so it marks the address as abandoned (before picking another one). That address will then never be offered again unless the server runs out of addresses and is forced to start recovering abandoned addresses. I'm not sure whether that address will be given to a client that requests it in a renew packet.

2) It gets no reply to the ping and offers it to the client. There are now two more options :

2a) The client checks and finds there is no other client using the address, and configures itself with the address offered. But, there may well be another client with a valid lease for that address, and when it re-connects to the network it will try to use it's non-expired lease. It may detect this and dump the lease before asking for a new one; or it may just configure the address and cause a conflict; or it may just not configure the interface.
Bear in mind that many wireless networks use client isolation - so one client may not be able to determine that the address offered is in use and you will therefore get a conflict.

2b) The client detects that the address is in use and declines to take it from the server. IIRC I've seen situations where the client then asks for a lease, the server picks the same one again, the client nacks it, and the cycle repeats - so a client is unable to get an address.


In short, there are various event timelines (some quite subtle) that can result in hard to diagnose problems - so it's a good idea to not dump your leases file !
In practice you may well be OK, but there are so many variables such as lease lengths, client volatility/type, network settings (eg client isolation on wireless), ... that you can't really say for sure exactly what will happen.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: [Already SOLVED] Precious leases?

Nicolas Ecarnot
Thank you to Eugene and Simon for sharing their hints.

Have a nice day.

--
Nicolas ECARNOT
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: [Already SOLVED] Precious leases?

Bill Shirley-2
One other hiccup no one has mentioned, if your doing ddns-updates the lease contains
the DNS info that's needed to check before re-updating the DNS:
  set ddns-fwd-name = "ACCTSPAYABLE.lan.example.com";
  set ddns-txt = "316acfa54bde0d7d2b1f5a7c91e4cd35b8";
  set ddns-rev-name = "165.1.98.10.in-addr.arpa";

In the log file you'll get a lot of messages like:
Forward map from ACCTSPAYABLE.lan.example.com to 10.98.1.165 FAILED: Has an address record but no DHCID, not mine.

Bill

On 12/11/2017 5:18 PM, Nicolas Ecarnot wrote:
Thank you to Eugene and Simon for sharing their hints.

Have a nice day.



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