static IP allocations in dynamic ranges -why not?

[Dorsey, Chris]

My question:
What is the technical reason why dhcpd cannot mix static addresses within dynamic ranges?  I've been pouring over the list archives, and there are snippets from various folks that say to avoid this because 'bad things will happen', especially related to the dhcpd IP allocator giving out your static IP to other dynamic clients possibly causing IP conflicts.

It seems to me that dhcpd knows about both previous dynamic and static allocations so it should be able to prevent allocating the given static IP for MAC address 'A' out to dynamic clients that do not have the MAC address 'A'. (i.e. before handing out a dynamic IP, check with the previously allocated dynamic IPs as well as static 'fixed-address' allocations for the given set of subnet(s))  This would help allow other scenarios including allowing a host to do static on one subnet and dynamic on others based solely on its MAC address.

Our scenario:
We want to be able to periodically 'pin' a MAC address to the last allocated IP address thereby disabling roaming while keeping the IP reachable, and at a later time 'unpin' from the last IP removing the 'fixed-address' statement and re-enable roaming.  Think of this as a dynamic-to-static conversion and eventual revert by doing a static-to-dynamic conversion.

We already use 'deny unknown-clients' in our dynamic ranges in order to avoid dynamic allocation for clients whose MAC address has not been known (registered but with no 'fixed-address' IP assignment in the host declaration), and are harvesting 'dhcpd.leases' to identify the last allocated IP address. We use 4.1.1 under Redhat 5 with primary/failover servers for fault tolerance.

I can think of a few approaches to this issue, but none seem attractive let alone be guaranteed to work:


1)      Dynamically generate the 'range' statements along with the 'host' statements such that when host 'A' becomes generated as a 'fixed-address', that address is then excluded from the 'range' statements for the related subnet.  The revert would also happen with static host 'A' being removed as a 'fixed-address' and the relevant 'range' statements being collapsed/merged to once again include the IP that was previously in the 'fixed-address' statement.  Host 'A' could then roam as normal and be served dynamically again.  This is the swiss-cheese option of configuring ranges (cheese) around the static (holes).



2)      Continue to use 'deny unknown-clients' in dynamic ranges as we do today without 'fixed-address' statements in the host declarations, but create a new subclass of these 'special' MAC addresses when the pin/unpin requirement changes and apply the following to the dynamic pools.
deny members of "special-static-clients";

The 'special-static-clients' include file would then contain the 'subclass special-static-clients' statements that enumerate the pinned list of MAC addresses.  A separate include file would also contain the 'host' declarations and 'fixed-address' statements for the pinned list of MAC addresses.  Unclear if the dynamic IP allocator would even care about this option since it would still see this as a static allocation within a dynamic range.  After writing this, I don't think this would even work.   Ideally I guess this option boils down to finding the right syntax to deny allocating a set of IPs to dynamic clients.


3)      Beg/bribe the dhcpd development community to allow static allocations within dynamic ranges  as described in the top of this post, or hack dhcpd ourselves.


4)      Other?

Thanks in advance, all feedback welcome,
Chris Dorsey
dorsey2 at llnl.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100602/bd925b3b/attachment.html>