A Question on Dynamic DHCP/DNS IP Lease Renew

[David Li]

We are using Dynamic DHCP/DNS with ISC DHCP and DNS server on Centos 7.
That is our DHCP server assigns an IP from a range based on the MAC address.
It will then update the DNS record with the IP and hostname.

For example:


Here are a few relevant lines from  /etc/dhcp/dhcpd.conf to assign IP
with hostname "node-1-1" to a server with MAC address
10:00:00:7a:a9:98

#
# Subnet and range
#
subnet 10.3.2.32 netmask 255.255.255.224 {


  option routers 10.3.2.33;

  range 10.3.2.35 10.3.2.44;


#
# host name and MAC
#
host node-1-1 {

  hardware ethernet   10:00:00:7a:a9:98;

  option host-name    "node-1-1";

}


This will result in a entry in the DNS entry like this:



node-1-1 A 10.3.2.38

TXT "003a7e20199e62a68504ff027bf35b1d78"


My question is: if the server is rebooted, will it come back and be
assigned the same IP 10.3.2.38 again as long as its MAC stays the
same?

I tested a few times and it seemed to be the case. Are there any
circumstances that a different IP will be assigned to the same server?



Thanks.

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

[Simon Hobson]

David Li <[hidden email]> wrote:

> My question is: if the server is rebooted, will it come back and be
> assigned the same IP 10.3.2.38 again as long as its MAC stays the
> same?
>
> I tested a few times and it seemed to be the case. Are there any
> circumstances that a different IP will be assigned to the same server?

Yes - mostly.

The server will attempt to give every client the same address as it had previously. If the address has not been reassigned to another client, then this will happen. At this point, it's probably worth setting out the allocation algorithm used by the ISC server (other servers operate differently, and mostly in a non-RFC-compliant manner).

In the following, everything is subject to admin restrictions/policies - eg by allow/deny rules ...
If a client has previously had an address from this server appropriate to the network segment AND that address is still available AND the address is permitted to be allocated to the client THEN the client will be given that address. Otherwise a different address will be allocated as follows :
If there are any "never used" addresses available then one of those will be allocated.
Else an expired lease will be recycled - based on least recently used.
If there are no free leases, then any abandoned leases will be recycled.
If we get to this point, then there's no address available.

So for a device to lose it's address, regardless of how long it's been off the network and it's lease expired, there must have been enough client churn for the address to have been reused in accordance with the above.

Lastly, there is the definition of client. The primary key for the lease database is the Client-ID, and only if that is missing will the client MAC be used. This means that if the Client-ID changes - or if it's missing, the MAC - then the client is deemed to be a different client.
There is also the issue of multiple client OSs. Windows defaults to using the MAC address as Client-ID, most other OSs default to leaving it blank - thus the client will appear as two different clients to the server. Eg when using PXE - at every boot the PXE client gets one address, then the OS gets a different one.


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

[David Li]

Hi Simon,

Thanks for the explanation. It seems like most of the cases the IP
will be the same after reboot unless it's taken somehow.

What if I want a fixed IP assignment to the server?

Should I use "fixed address":

#
# host name and MAC
#
host node-1-1 {

  hardware ethernet   10:00:00:7a:a9:98;

  option host-name    "node-1-1";

  fixed-address 10.3.2.38;

}

My concern is will this work with Dynamic DNS update?


Or is there a "dynamic address allocation algorithm" option I can use
to fix the assignment?


David

> ------------------------------
>
> Message: 6
> Date: Wed, 28 Sep 2016 22:30:31 +0100
> From: Simon Hobson <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> David Li <[hidden email]> wrote:
>
>> My question is: if the server is rebooted, will it come back and be
>> assigned the same IP 10.3.2.38 again as long as its MAC stays the
>> same?
>>
>> I tested a few times and it seemed to be the case. Are there any
>> circumstances that a different IP will be assigned to the same server?
>
> Yes - mostly.
>
> The server will attempt to give every client the same address as it had previously. If the address has not been reassigned to another client, then this will happen. At this point, it's probably worth setting out the allocation algorithm used by the ISC server (other servers operate differently, and mostly in a non-RFC-compliant manner).
>
> In the following, everything is subject to admin restrictions/policies - eg by allow/deny rules ...
> If a client has previously had an address from this server appropriate to the network segment AND that address is still available AND the address is permitted to be allocated to the client THEN the client will be given that address. Otherwise a different address will be allocated as follows :
> If there are any "never used" addresses available then one of those will be allocated.
> Else an expired lease will be recycled - based on least recently used.
> If there are no free leases, then any abandoned leases will be recycled.
> If we get to this point, then there's no address available.
>
> So for a device to lose it's address, regardless of how long it's been off the network and it's lease expired, there must have been enough client churn for the address to have been reused in accordance with the above.
>
> Lastly, there is the definition of client. The primary key for the lease database is the Client-ID, and only if that is missing will the client MAC be used. This means that if the Client-ID changes - or if it's missing, the MAC - then the client is deemed to be a different client.
> There is also the issue of multiple client OSs. Windows defaults to using the MAC address as Client-ID, most other OSs default to leaving it blank - thus the client will appear as two different clients to the server. Eg when using PXE - at every boot the PXE client gets one address, then the OS gets a different one.
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> ------------------------------
>
> End of dhcp-users Digest, Vol 95, Issue 15
> ******************************************

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

[Simon Hobson]

David Li <[hidden email]> wrote:

> Thanks for the explanation. It seems like most of the cases the IP
> will be the same after reboot unless it's taken somehow.

Yes, in the general case with a device that's mostly on, it will actually be hard for it to lose it's address. For addresses to change you need to be off the network for a "long" time - where "long" is a function of the amount of available address space and client churn.

> Should I use "fixed address":

When you use a "fixed-address" declaration, the lease processing is bypassed. From the client side it looks the same, but the server doesn't do any lease lifetime actions - it's not recorded in the leases file, it doesn't (by default) do DDNS, and there's no lease to expire. There's a setting to make the server do DDNS for fixed-addresses - but all it does is force add/update of the records on every lease issue/renew (for fixed-address statements), as there's no lease to expire, the DNS entries never get removed.

As an alternative, add the "reserved" statement to the lease. You can either stop the server and edit the leases file (whether that's to add it to an existing lease or to add a skeleton new lease in advance) or (AIUI) use OMAPI to set it. This reserves the lease so it won't get re-used for another client, so it has the same effect of fixing the address but in a manner that doesn't interfere with normal lease processes & DDNS.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[David Li]

Hi Simon,

Thanks again. This is most clearly explained I have seen so far how
DDNS works in terms of IP leases.

Is the "reserved" statement something I need to add to the
/var/lib/dhcp/dhcpd.leases?

When I look at that file, it appears to have two identical leases for
the same IP address:


lease 10.3.2.38 {

  starts 4 2016/09/29 17:38:21;

  ends 4 2016/09/29 18:38:21;

  cltt 4 2016/09/29 17:38:21;

  binding state active;

  next binding state free;

  rewind binding state free;

  hardware ethernet 08:00:27:33:11:11;

  set ddns-txt = "00e53536ceb5e56f6af495330028571738";

  set ddns-fwd-name = "node-1-1.rack1.com.";

  client-hostname "node-1-1";

}

server-duid "\000\001\000\001\037c\002\364D89\000\000\023";


lease 10.3.2.38 {

  starts 4 2016/09/29 18:03:29;

  ends 4 2016/09/29 19:03:29;

  cltt 4 2016/09/29 18:03:29;

  binding state active;

  next binding state free;

  rewind binding state free;

  hardware ethernet 08:00:27:33:11:11;

  set ddns-txt = "00e53536ceb5e56f6af495330028571738";

  set ddns-fwd-name = "node-1-1.rack1.com.";

  client-hostname "node-1-1";

}

Questions:

1. Why are there two identical leases?
2. Should I add "reserved;" to both of them?
3. Can this be done without restarting dhcpd?



David


On Thu, Sep 29, 2016 at 5:00 AM,  <[hidden email]> wrote:

> Send dhcp-users mailing list submissions to
>         [hidden email]
>
> 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
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dhcp-users digest..."
>
>
> Today's Topics:
>
>    1. Re: A Question on Dynamic DHCP/DNS IP Lease Renew (David Li)
>    2. Re: A Question on Dynamic DHCP/DNS IP Lease Renew (Simon Hobson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Sep 2016 18:34:22 -0700
> From: David Li <[hidden email]>
> To: [hidden email]
> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
> Message-ID:
>         <CAEuTsAwXLizxZ=B=3m_=[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Simon,
>
> Thanks for the explanation. It seems like most of the cases the IP
> will be the same after reboot unless it's taken somehow.
>
> What if I want a fixed IP assignment to the server?
>
> Should I use "fixed address":
>
> #
> # host name and MAC
> #
> host node-1-1 {
>
>   hardware ethernet   10:00:00:7a:a9:98;
>
>   option host-name    "node-1-1";
>
>   fixed-address 10.3.2.38;
>
> }
>
> My concern is will this work with Dynamic DNS update?
>
>
> Or is there a "dynamic address allocation algorithm" option I can use
> to fix the assignment?
>
>
> David
>
>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 28 Sep 2016 22:30:31 +0100
>> From: Simon Hobson <[hidden email]>
>> To: Users of ISC DHCP <[hidden email]>
>> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=us-ascii
>>
>> David Li <[hidden email]> wrote:
>>
>>> My question is: if the server is rebooted, will it come back and be
>>> assigned the same IP 10.3.2.38 again as long as its MAC stays the
>>> same?
>>>
>>> I tested a few times and it seemed to be the case. Are there any
>>> circumstances that a different IP will be assigned to the same server?
>>
>> Yes - mostly.
>>
>> The server will attempt to give every client the same address as it had previously. If the address has not been reassigned to another client, then this will happen. At this point, it's probably worth setting out the allocation algorithm used by the ISC server (other servers operate differently, and mostly in a non-RFC-compliant manner).
>>
>> In the following, everything is subject to admin restrictions/policies - eg by allow/deny rules ...
>> If a client has previously had an address from this server appropriate to the network segment AND that address is still available AND the address is permitted to be allocated to the client THEN the client will be given that address. Otherwise a different address will be allocated as follows :
>> If there are any "never used" addresses available then one of those will be allocated.
>> Else an expired lease will be recycled - based on least recently used.
>> If there are no free leases, then any abandoned leases will be recycled.
>> If we get to this point, then there's no address available.
>>
>> So for a device to lose it's address, regardless of how long it's been off the network and it's lease expired, there must have been enough client churn for the address to have been reused in accordance with the above.
>>
>> Lastly, there is the definition of client. The primary key for the lease database is the Client-ID, and only if that is missing will the client MAC be used. This means that if the Client-ID changes - or if it's missing, the MAC - then the client is deemed to be a different client.
>> There is also the issue of multiple client OSs. Windows defaults to using the MAC address as Client-ID, most other OSs default to leaving it blank - thus the client will appear as two different clients to the server. Eg when using PXE - at every boot the PXE client gets one address, then the OS gets a different one.
>>
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>> ------------------------------
>>
>> End of dhcp-users Digest, Vol 95, Issue 15
>> ******************************************
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 29 Sep 2016 08:05:54 +0100
> From: Simon Hobson <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> David Li <[hidden email]> wrote:
>
>> Thanks for the explanation. It seems like most of the cases the IP
>> will be the same after reboot unless it's taken somehow.
>
> Yes, in the general case with a device that's mostly on, it will actually be hard for it to lose it's address. For addresses to change you need to be off the network for a "long" time - where "long" is a function of the amount of available address space and client churn.
>
>> Should I use "fixed address":
>
> When you use a "fixed-address" declaration, the lease processing is bypassed. From the client side it looks the same, but the server doesn't do any lease lifetime actions - it's not recorded in the leases file, it doesn't (by default) do DDNS, and there's no lease to expire. There's a setting to make the server do DDNS for fixed-addresses - but all it does is force add/update of the records on every lease issue/renew (for fixed-address statements), as there's no lease to expire, the DNS entries never get removed.
>
> As an alternative, add the "reserved" statement to the lease. You can either stop the server and edit the leases file (whether that's to add it to an existing lease or to add a skeleton new lease in advance) or (AIUI) use OMAPI to set it. This reserves the lease so it won't get re-used for another client, so it has the same effect of fixing the address but in a manner that doesn't interfere with normal lease processes & DDNS.
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> ------------------------------
>
> End of dhcp-users Digest, Vol 95, Issue 16
> ******************************************

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

[Simon Hobson]

David Li <[hidden email]> wrote:

> Thanks again. This is most clearly explained I have seen so far how DDNS works in terms of IP leases.

Thanks, nice to know I can get some things right :-)

> Is the "reserved" statement something I need to add to the /var/lib/dhcp/dhcpd.leases?

Yes

> When I look at that file, it appears to have two identical leases for the same IP address:

They aren't identical :

>  starts 4 2016/09/29 17:38:21;
>  starts 4 2016/09/29 18:03:29;


> Questions:
>
> 1. Why are there two identical leases?

There aren't.
The explanation is that the leases database is an "append only" format for performance and security reasons. When the server issues a lease, it is required by the RFC to commit that information to persistent storage BEFORE offering it to the client. The fastest form of database is to just append a record to the file.
So the two leases you have found are actually separate ones - one starting at 17:38 and the next starting at 18:03. The last record in the file is the current version, all the previous ones can and will be ignored.

While the server is running, this is a write only file - it is only ever read **ONCE** during server startup when it populates it's internal data structures from the file.

To avoid the file expanding forever, the server re-writes it periodically - by default every hour (compile time option). The new file contains only one record for each lease fetched from the server's internal data structures, is written to a new file, the old file is renamed, and the new file renamed into place - thus making the file replacement almost atomic. The second file (with a timestamp up to an hour earlier than the leases file, is the old version.

> 2. Should I add "reserved;" to both of them?

Only the last - the others aren't used.

> 3. Can this be done without restarting dhcpd?

Only if you use OMAPI.
If you don't use OMAPI you must stop the server before editing the file - otherwise it may append to it while you are editing, or replace it entirely if it does it's cleanup routine. You have to stop and start the server anyway for it to read the file during startup and see any changes you make.

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

[Frank Price]

On Thu, Sep 29, 2016 at 3:00 PM, Simon Hobson <[hidden email]> wrote:

> 2. Should I add "reserved;" to both of them?

Only the last - the others aren't used.

> 3. Can this be done without restarting dhcpd?

Only if you use OMAPI.
If you don't use OMAPI you must stop the server before editing the file - otherwise it may append to it while you are editing, or replace it entirely if it does it's cleanup routine. You have to stop and start the server anyway for it to read the file during startup and see any changes you make.

If anyone has a proven set of OMAPI commands (shell script, whatever) for setting a reserved lease, I'd love to see it.  I've never been able to make it work in my environment :-(

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

[glenn.satchell]

On Fri, September 30, 2016 5:34 am, Frank Price wrote:

> On Thu, Sep 29, 2016 at 3:00 PM, Simon Hobson <[hidden email]>
> wrote:
>
>> > 2. Should I add "reserved;" to both of them?
>>
>> Only the last - the others aren't used.
>>
>> > 3. Can this be done without restarting dhcpd?
>>
>> Only if you use OMAPI.
>> If you don't use OMAPI you must stop the server before editing the file
>> -
>> otherwise it may append to it while you are editing, or replace it
>> entirely
>> if it does it's cleanup routine. You have to stop and start the server
>> anyway for it to read the file during startup and see any changes you
>> make.
>
>
> If anyone has a proven set of OMAPI commands (shell script, whatever) for
> setting a reserved lease, I'd love to see it.  I've never been able to
> make
> it work in my environment :-(

As an alternative you can just set a really long lease time, like a year
or two. You can do this with a host statement for the particular systems
and put a group around it. Something like

group {
  # 365 days
  min-lease-time 31536000;
  host foo {
    hardware ethernet ..... ;
  }
  host bar {
    hardware ethernet .... ;
  }
}

Note that any system that is online renews it's lease typically half way
through the lease, so systems that are online will always have a current
lease and the ip address won't be given away to another system.

regards,
-glenn

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

[Simon Hobson]

Glenn Satchell <[hidden email]> wrote:

> As an alternative you can just set a really long lease time, like a year
> or two.

But bear in mind that some systems explicitly release their leases on shutdown. So does that negate the long lease when it comes to the "least recently used" calculation ?


As an aside ...
I once had a printer (early generation of connected digital copiers) that just would not accept a lease via DHCP. I gave up in the end and manually configured it. Some time later I found that it had a requirement that any lease offered must be a minimum of 2 years. That was a WTF moment, and I had some questions about the parentage of the devs that came up with that requirement !

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

[Simon Hobson]

Rather amusingly, I've had a notification that my last email was blocked to one person. Someone has some interesting ideas of what is pornography !

> Bell Aliant Content Filtering Device:
> ...
> Content Rule: Policy Management (Inbound) : Block Pornographic Language - BA


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

[glenn.satchell]

On Fri, September 30, 2016 5:09 pm, Simon Hobson wrote:

> Glenn Satchell <[hidden email]> wrote:
>
>> As an alternative you can just set a really long lease time, like a year
>> or two.
>
> But bear in mind that some systems explicitly release their leases on
> shutdown. So does that negate the long lease when it comes to the "least
> recently used" calculation ?
>
>
> As an aside ...
> I once had a printer (early generation of connected digital copiers) that
> just would not accept a lease via DHCP. I gave up in the end and manually
> configured it. Some time later I found that it had a requirement that any
> lease offered must be a minimum of 2 years. That was a WTF moment, and I
> had some questions about the parentage of the devs that came up with that
> requirement !

I recently resurrected an old HP UPS at work, and the management card
would only use bootp, so my normal range statement didn't help. In that
case host statement with fixed-address did the job.

regards,
-glenn


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

[glenn.satchell]

Hi Simon

I think you will find it is the term used in the dhcpd.leases file, which
defines the client's last transaction time. If you look up dhcpd.leases
man page you'll find the acronym.

Looks like over-zealous pattern matching. It's been in their anti-spam
filters for many years. I even emailed the user once and he said it was
the corporate anti-spam filter and just too hard to get it changed.

regards,
-glenn

On Fri, September 30, 2016 7:07 pm, Simon Hobson wrote:

> Rather amusingly, I've had a notification that my last email was blocked
> to one person. Someone has some interesting ideas of what is pornography !
>
>> Bell Aliant Content Filtering Device:
>> ...
>> Content Rule: Policy Management (Inbound) : Block Pornographic Language
>> - BA
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

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