best practice for fixed-address / reserved leases

Thu Dec 31 00:31:41 UTC 2020

Bill, Simon: Many thanks for the answers, both: The short and the long version!
I'm glad to read all that and it helps to explain why we use that "best practice". It's perfect to also get a better understanding of the difference between the ISC server and the Windows service, as exactly that is to be explained most of the time. 

PS: Good that you mentioned it, Bill: This was a really bad example with subnet and addresses not being part of the RFC 1918 range. Please: Do not copy/paste this example into your environment. I just wrote down some "numbers" (even with a mistake). Important to me was to show that the fixed-address is outside the defined range.

Very much appreciated,
Michael

On 30.12.20, 22:22, "dhcp-users on behalf of Simon Hobson" <dhcp-users-bounces at lists.isc.org on behalf of dhcp1 at thehobsons.co.uk> wrote:

    Bill Shirley <bill at c3po.polymerindustries.biz> wrote:

    > Fixed addresses should NOT be in any range.  It's possible for DHCP to assign that address
    > before the device with that fixed address gets it.

    To expand on that a bit ...

    The ISC server (and I'm talking dhcpd here, not Kea which I'm not familiar with) is very different to the Windows service many people are familiar with. With the Windows service, your fixed addresses are part of the range (which is usually defined as the whole of the usable subnet with sections reserved so they aren't used). With the ISC server the fixed addresses are treated somewhat differently to dynamic clients and the server makes no attempt whatsoever to exclude them from the dynamic ranges - so as Bill says, it's entirely possible for a dynamic client to be given the address.

    But you may be thinking that this would be hard to do - after all, the fixed address device has it leased to it doesn't it ? Well no it doesn't - the ISC server does not track address status for fixed address assignments - in theory it doesn't need to. Simply put, the admin has said that there's a one-one mapping between that address and a device - so it can only ever be leased to that device, and it really doesn't matter about keeping lease state for it. So there is no lease record kept - the server just bypasses all of that.
    So when a dynamic client comes along for a lease, and according to whatever rules are in place (more on that later), that fixed address happens to be the one selected for the dynamic client - then it will be selected. If the fixed address devices is offline at the time OR it is configured to not respond to pings OR the server is configured not to do it's "ping before offer" check - then the address will be leased to the client and you now have an address collision. That "ping before offer" is your safety net in these cases, it defaults to on, and if the device is both online and replies to a ping, then the server will flag the dynamic lease as abandoned and it won't be offered to anything again (except the fixed address device) unless there really is nothing left to offer.

    Now, about that address selection policy ?
    Here is another big difference from the Windows service. From memory, the Windows service tends to allocate addresses from the bottom of the available pool - and will happily re-allocate an address when it's not in use. So if you have a fixed address high up in the range, it may be a long time (or even never) before your dynamic assignments get up to it. In the Windows world, a lot of what is supposed to happen at the server end according to the RFCs is actually fudged by making the clients very clingy to their previously leased address.
    With the ISC server, dynamic address assignment is done very differently, and follows these rules - always following any allow/deny conditions attached to a pool. The address offered will be the first found of :
    1) A previously never used address - working (as an undocumented and not guaranteed to not change without warning implementation detail) top-down in a list of all addresses available to be given to the client.
    2) If there are no "never used" addresses, then a free lease (i.e. one that's expired or been released by the client) working on a least recently used basis.
    Under normal operations, these will be the only cases used. By default, the server will ping an address before it offers it to the client - if it gets a reply then it will mark the lease as abandoned, after which it will never get selected again unless ...
    3) If there are no free leases to be offered, but there are abandoned ones, then it will try one of the abandoned ones - if it gets no reply to a ping then it will change it to free and then offer it to the client as in 2) above.

    There's also something about leases made to bootp clients. IIRC, because bootp doesn't have a concept of lease time, all such leases are infinite and can't be re-allocated.

    Reading the above, you can probably see why most people have no problem most of the time - to the extent that I've seen some "rather poor" advice in the past. In one case I recall, someone offered a script that monitored the dhcp logs, detected when you plugged in an IP phone, then added a fixed-IP statement (within a host record) for that device to the dhcp config, and configured the IP PBX to use the new device. I had a discussion with the author of the script who declared "so ping will fix it, no problem, nothing to fix".
    IFF ping before offer is left on AND the device responds to pings AND it is online when it's address first gets picked for a dynamic clients - THEN the address will be abandoned, and IFF you never run out of free addresses then you won't have a problem.
    MOST of the time that will be the case, but it's not 100% guaranteed to work, and when it doesn't then you can get some "interesting" issues.

    So there's the detail as to why you should NEVER configure a fixed-address that is within a dynamic range. Stick to that rule and you won't have a problem with it, break it and you probably won't have a problem - but when you do it'll be a long time down the road and cause you some head scratching.

    For completeness, you may have spotted a little detail implied by the "bypasses the normal lease processing" bit above. That also means there are no DNS updates done for fixed-addresses - you'd normally manually configure the DNS, and you can use a DNS name in place of the IP address in the DHCP config. You can configure the server to do DNS updates for fixed-addresses - but then it will blindly do them EVERY time a fixed address requests or renews a lease (performance issue), and it will never remove them (you'll have to manually remove them).

    BTW - there is an alternative to fixed-addresses. If you create a skeleton lease (which must be within a range) and mark it as reserved, or add a line to an existing lease record, then that lease will be reserved to that client. In practical terms, this means the lease goes through the normal lease cycles including adding/removing the DNS records as the lease becomes active or free. The only difference is that when in the free state, the address cannot be re-allocated to another client.
    You can either manually edit the leases file while the server is shut down, or I believe it can be done via OMAPI.

    On the upside, such reserved addresses work the same way as dynamic addresses, just with the address being tied to a client in the same way as "fixed-address" does. And they can be within a dynamic range - making it easy to plug a device in, see what address it gets, and simply mark that lease as reserved.
    On the downside, they don't appear anywhere in the config - the only place to see them is in the leases database (or with tools that will parse the leases database for you).

    A dynamic lease configured as "reserved" is much closer in operation to the reserved addresses in the Windows DHCP service.

    Simon

    _______________________________________________
    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

    dhcp-users mailing list
    dhcp-users at lists.isc.org
    https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5898 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20201231/acc3ad6a/attachment-0001.bin>