Send dhcp-users mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."

Today's Topics:

   1. Re: Move dhcp lease to new ip+reservation. How? (Gregory Sloop)


Message: 1
Date: Sun, 29 Aug 2021 17:15:12 -0700
From: Gregory Sloop <>
To: Users of ISC DHCP <>
Subject: Re: Move dhcp lease to new ip+reservation. How?
Message-ID: <>
Content-Type: text/plain; charset="utf-8"

An HTML attachment was scrubbed...
-------------- next part --------------
I started down the road of moving and reserving leases via OMAPI - but I can't 
find a way to *create* leases in OMAPI. (I find no cases/threads where anyone 
has confirmed the ability to create a new lease, and quite a few threads 
claiming I think it's safe to say/assume, that you can't create 
leases in OMAPI.) So, that kills that approach. Simon's way of hand-editing was 
great, but it's too klunky/fragile for this use case.
Since I run fail-over and hand-editing the leases file isn't a trivial exercise 
- the classes route seemed as good as it gets.
Honestly, I should have looked at it more carefully before I sunk the time into 
trying to do it in OMAPI. (I won't get those hours back! Ugh!)
Frankly it's pretty easy.
I have to try an actual live move of a host from the "regular" pool, to 
defining the host mac address and subclass - and then seeing what happens. (It 
should get a NAK on renewal and "move" into the special/subclass pool.)
A big benefit is that I have a campus network, and we'll be defining pools for 
each location - with a similar set of pools at each location.
That means if a printer (for one example) gets picked up and moved from one 
building to another, it will end up in that building's printer pool.
We'll have to manage the sub-pool allocation carefully, but I think that's 
do-able. (So we don't run out of addresses available for devices in those 
But this makes it pretty easy - and doesn't require a lot of gyrations to work 
I can see putting lots more devices into classes and then letting them find 
their ways into the proper pools/blocks too.
Thanks for helping teach this old dog new tricks! :)
It looks something like this: (In case anyone wants a quick example.)
class "Printers" {
? ? match hardware;

subclass "Printers" 1:00:00:00:00:00:01;? #some printer
subnet netmask {
ignore bootp;
ignore client-updates;
option routers? ? ? ? ? ? ? ? ?;
option subnet-mask? ? ? ? ? ? ?;
# Two blocks 31-60, 61-90
pool {
deny members of "Printers";
#thus: allow all others;
pool {
allow members of "Printers";
#Thus: dis-allow all others;
For anyone following along - I think the "allow" and "deny" statements can be 
Make sure they actually do what you intend, not just what you _think_ they do.

Again, thanks all!

> Hi Greg,
> What about using a class for the 51-70 pool and use sub-classes to define the 
> allowed mac addresses? There's an example in the dhcpd.conf man page, a bit 
> like this. The leading 1 is added to the mac address to indicate hardware 
> type 1 (ethernet).
> class "allocation-class-2" {
> match pick-first-value (option dhcp-client-identifier, hardware);
> }
> subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
> subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
> subclass "allocation-class-1" 1:0:0:c4:aa:29:44;

> regards,
> Glenn
> On 2021-08-27 13:37, Gregory Sloop wrote:
>> I have a subnet in dhcpd - lets just assume
>> (It's a fail-over served pool - if that matters.)

>> I have a pool where unknown-clients are allowed

>> I'd like to add a new lease for a machine where the IP is outside the 
>> unknown pool above. (I don't want to use a host definition with an IP in the 
>> conf files, because I want the ddns name to get added via the DDNS 
>> mechanisms - which doesn't happen in that case. Plus, if this machine/device 
>> gets moved to another subnet, and the host def is still there, it won't get 
>> ANY lease in the new subnet - which is bad. I'd like the device to still 
>> function if it gets dropped into a new subnet, even if it's not getting a 
>> "special" ip any more.)

>> This new machine/device may have already been added to the network and 
>> currently has an address in the 192.168.21-40 pool.

>> Lets assume I'd like to assign it - and set a reservation.?
>> Lets assume that I'll have several machines I'd like set as "static" between 
>> 51-70.?
>> But I don't want just "any" machine to get one of these "special" addresses 
>> in the 51-70 range.

>> What's the best way to go about this?

>> ---
>> Some thoughts I've had, but this gets complicated.

>> ---
>> I don't believe I can just add or modify the lease without changing the 
>> pool, because even if there's a defined lease, this is still an unknown 
>> client. So, even if there's a reserved lease for - the DHCP 
>> server won't give out that address because this is an unknown client. 
>> (Right?)

>> Yet if I make a pool for 51-70 and allow unknown clients, then any client 
>> might (will) get one - not just the ones I want to "move" there.

>> I've thought about pre-creating leases for 51-70 and essentially adding 
>> "bogus" information for those leases and reserving them. (While allowing 
>> unknown-clients for the 51-70 pool - but since they're all "taken" it won't 
>> hand one out),? Then when I want to move something there, I can remove the 
>> "bogus" reservation and move the "real" lease to the appropriate IP in the 
>> 51-70 block/pool.

>> ---
>> Or define the MAC address in a host definition, without an IP definition. (I 
>> think DDNS works in this case.)
>> Then define the 192.168.51-70 pool as "known" hosts only. (And make sure no 
>> "other" known hosts accidentally grab one of the IP's in this pool. This 
>> part worries me.)

>> But it seems like I must be making this too hard.
>> Am I missing something?

>> Surely someone else has done this and can point me a tried-and-true solution 
>> that works without a ton of drama. :)

>> (Yes, my pools are larger than those, but the details are essentially the 
>> same - this example is just more manageable.)

>> Thanks!
>> -Greg 

>> _______________________________________________
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at for more information.

>> dhcp-users mailing list


Subject: Digest Footer

ISC funds the development of this software with paid support subscriptions. 
Contact us at for more information.

dhcp-users mailing list


End of dhcp-users Digest, Vol 154, Issue 10

Reply via email to