A Question on Dynamic DHCP/DNS IP Lease Renew
David Li
dlipubkey at gmail.com
Thu Sep 29 18:26:51 UTC 2016
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, <dhcp-users-request at lists.isc.org> wrote:
> Send dhcp-users mailing list submissions to
> dhcp-users at 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-request at lists.isc.org
>
> You can reach the person managing the list at
> dhcp-users-owner at 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: 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 <dlipubkey at gmail.com>
> To: dhcp-users at lists.isc.org
> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
> Message-ID:
> <CAEuTsAwXLizxZ=B=3m_=MuJnNONiYHA0FETx0gpkNtedoTcpUQ at mail.gmail.com>
> 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 <dhcp1 at thehobsons.co.uk>
>> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
>> Message-ID: <A25B5C53-6596-4708-A16A-F4D3EE1BC1DE at thehobsons.co.uk>
>> Content-Type: text/plain; charset=us-ascii
>>
>> David Li <dlipubkey at gmail.com> 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
>> dhcp-users at lists.isc.org
>> 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 <dhcp1 at thehobsons.co.uk>
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: Re: A Question on Dynamic DHCP/DNS IP Lease Renew
> Message-ID: <45F34719-FC98-463A-A6A9-38C6215763FB at thehobsons.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> David Li <dlipubkey at gmail.com> 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
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> ------------------------------
>
> End of dhcp-users Digest, Vol 95, Issue 16
> ******************************************
More information about the dhcp-users
mailing list