static IP allocations in dynamic ranges -why not?

Glenn Satchell glenn.satchell at
Thu Jun 3 02:11:07 UTC 2010

On 06/03/10 11:21, Dorsey, Chris wrote:
> 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?
Hi Chris

What about giving the host a really *long* lease time, say weeks, or 
months? This means you wouldn't need to mangle ranges and this host 
would keep it's lease for "long enough". You could do this by either 
having a class and making the mac addresses members of a sub-class, or 
using host statements without fixed-address, perhaps in a group.

Another option might be to enable DDNS, and refer to all hosts by fully 
qualified host names? Then it doesn't matter so much if the IP changes.

A third option might be the use of reserved leases, where a given lease 
will only be assigned to the current client.

The problem is that in the original design statically assigned hosts go 
through a different, simplified path in the code, so there aren't nice 
efficient hashed lists of static hosts to lookup, for example. I believe 
that this would be a fairly large modification.


More information about the dhcp-users mailing list