so many lease records for one lease

[Simon Hobson]

Luc T. wrote:

>lease 192.168.31.120 {
>   starts 0 2007/01/21 20:21:50;
>   ends 0 2007/01/21 21:21:50;
>   binding state active;
>   next binding state free;
>   hardware ethernet 00:15:00:23:ee:1a;
>   uid "\001\000\025\000#\356\032";
>   client-hostname "PC172323126029";
>}
>lease 192.168.31.120 {
>   starts 0 2007/01/21 20:22:36;
>   ends 0 2007/01/21 21:22:36;
>   binding state active;
>   next binding state free;
>   hardware ethernet 00:15:00:23:ee:1a;
>   uid "\001\000\025\000#\356\032";
>   client-hostname "PC172323126029";
>}



>   why are there so many records for the same ip, e.g. 31.120 and 
>31.44 in the above example?

So many questions in such a short space of time !

The actual lease database is (as David pointed out) in memory. 
However, the rfc specifies that before a lease can be given to a 
client a permanent record of it must have been written to 
non-volatile storage. This is so that should the server crash (or 
whatever), on restart it will have information on all the promises it 
made before - and so will not offer the same address to another 
client.

In the case of the ISC server, the way they do this is to append a 
record to the leases file on disk every time anything happens which 
changes that record. Ie, the file is only ever appended to, never 
modified, which makes it simple quick and safe to do.

In the the case of the two records I've left quoted above, a 1 hour 
leases was handed out at 20:21:50, then 45s later (20:22:36) it was 
handed out again - we cannot say why, only that it happened. To find 
the currently valid entry when there is more than one, you simply 
look for the one which is physically later in the file.


When the server starts up, it has to prime it's in-memory database 
from the leases file, so it simply reads it one record at a time and 
adds or updates the in-memory structures to match. If it read just 
the two records above, then in memory it would hold a record of ONE 
lease starting at 20:22:36 and ending at 21:22:36.