Send dhcp-users mailing list submissions to dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/dhcp-users or, via email, send a message with subject or body 'help' to dhcp-users-requ...@lists.isc.org You can reach the person managing the list at dhcp-users-ow...@lists.isc.org 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 <gr...@sloop.net> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: Move dhcp lease to new ip+reservation. How? Message-ID: <139765826.20210829171...@sloop.net> Content-Type: text/plain; charset="utf-8" An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20210829/173b368e/attachment-0001.htm> -------------- next part -------------- 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 >> dhcp-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/dhcp-users ------------------------------ Subject: Digest Footer _______________________________________________ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users ------------------------------ End of dhcp-users Digest, Vol 154, Issue 10 *******************************************