Re: Move dhcp lease to new ip+reservation. How?

Glenn!
Thanks!
 
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 problems...so 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 pools.)
 
But this makes it pretty easy - and doesn't require a lot of gyrations to work well.
 
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 10.116.1.0 netmask 255.255.255.0 {
 
ignore bootp;
authoritative;
ignore client-updates;
option routers                  10.116.1.1;
option subnet-mask              255.255.255.0;
# Two blocks 31-60, 61-90
pool {
range 10.116.1.31 10.116.1.60;
deny members of "Printers";
#thus: allow all others;
}
pool {
range 10.116.1.61 10.116.1.90;
allow members of "Printers";
#Thus: dis-allow all others;
}
 
}
 
---
For anyone following along - I think the "allow" and "deny" statements can be tricky. 
Make sure they actually do what you intend, not just what you _think_ they do.

Again, thanks all!
 
-Greg
 

> 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 192.168.1.0/24
>> (It's a fail-over served pool - if that matters.)

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

>> 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 192.168.1.51 - 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 192.168.1.51 - 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 https://www.isc.org/contact/ for more information.

>> dhcp-users mailing list
>> [email protected]
>> 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
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users