Thank You Marcin.
You have understood exactly my problem, and it's worth noting that 3
subnets is only the beginning. Ultimately there will be upwards of 30
subnets, with 2 or 3 being dedicated to static clients. This would be 30
reservations stored and managed for each of several hundred clients.
That would get unruly very quickly.
It seems like Kea should check for reservations before assigning a
subnet in order to avoid this problem, but there may be another way
around this.
If I use the subnet4_select hook to intercept the request, check the
database for reservations in a callout function, modify the assigned
subnet and send the data back from the callout, then Kea should be able
to process the request using the subnet ID associated with the
reservation. I posted a few minutes ago asking for a code example of how
to do the modification of the subnet ID.
That's the only solution I could come up with to work around this
limitation. Did I miss another or better option?
And really, Thanks for the help.
Bryan
On 5/12/2016 11:27 AM, Marcin Siodelski wrote:
Hi Bryan,
Let me summarize your issue, so as we check if I understand it correctly:
- You have 3 subnets where you have DHCP clients, of which some have and
some don't have static reservations.
- Router (relay agent) will use one of 3 different giaddrs when relaying
messages to the server over a single link (relay-server link) connected
to a particular interface on the DHCP server.
- For clients for which addresses should be assigned dynamically we want
the server to use giaddr to pick the correct subnet.
- For other clients, which have static addresses, it is possible that
the giaddr may vary and in 2 out of 3 cases the client will not have a
subnet corresponding to his static reservation selected. As a result the
client will get a dynamically assigned address, rather than static one.
- You want to define a static reservation for a given client's MAC
address which should be used regardless of the giaddr appearing in a
relayed message.
The problem with this approach is that our host reservations are
strictly associated with a subnet (subnet id) selected for a client.
This selection takes place even before we check for host reservations.
The subnet id (and MAC address) is used as an input to search for static
reservations for a client.
I need to think a bit more about this issue, but for a time being, would
it be simply possible to insert 3 reservations for the same host,
differing by the subnet identifier? In that case, no matter which subnet
id is selected for the client, the server should always find a suitable
reservation. That may be not viable if I misunderstood your use case :-).
This also has an issue that you have redundant information in the
database and this doesn't scale well with many reservations.
Thanks,
Marcin Siodelski
ISC
On 11.05.2016 23:24, Bryan Perry wrote:
So any guidance from the ISC gurus on this topic? My host reservation
seems to work fine only if the correct subnet is assigned, but if a
different subnet (still part of the same shared network) is assigned
then the client gets a lease from a pool. If I lock down the upstream
router to only use the XXX.YYY.169.1 giaddr then normal DHCP clients who
need addresses from the 170 or 171 subnets get nothing.
Can I define multiple non-contiguous address pools inside the same
subnet declaration to handle both the static and dynamic clients?
I'm stumped. Thanks for any help.
-Bryan
On 5/10/2016 1:05 PM, Thomas Andersen wrote:
Not sure that you can, and I’m not sure it’s how it is intended.
But it’s a bit deeper than what i normally deal with.
Maybe one of the ISC guys can elaborate.
Br,
Thomas
On 10/05/16 20:58, "[email protected] on behalf of Bryan
Perry" <[email protected] on behalf of [email protected]>
wrote:
So the question becomes, how do I force it back to subnet 169 when the
DHCPDISCOVER comes in from the .170.1 relay address (which is the same
router) and the hosts entry is for subnet 169?
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
