best practice for fixed-address / reserved leases

[glenn.satchell at uniq.com.au]

Hi Michael,

One other alternative to a reserved lease (which is essentially infinite 
time) could be to set a very long lease, say a few months or 1 year - 
just make it a longer than any amount of time the system might be not on 
the network.

This can be done in dhcpd.conf, in this case a dynamic address from the 
pool is assigned. If there were a few of these they could be put in a 
group{} or a class.

host foo {
   hardware ethernet aa:bb:cc:dd:ee:ff;
   # 1 year in seconds
   min-lease-time 31536000;
}

class "long" {
   match pick-first-value (option dhcp-client-identifier, hardware);
   min-lease-time 31536000;
}
subclass "long" 1:aa:bb:cc:dd:ee:ff; # repeat for more devices

The other advantage here is that if the device is permanently removed 
from the network, eventually the lease will expire and be available for 
re-use by other systems.

regards,
Glenn

On 2020-12-31 11:31, Michael Schnyder wrote:
> 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
> 
> _______________________________________________
> 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