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
*******************************************
