Move your reservation clauses into the proper subnets.
Here's what I do (the reservation files are the ones ending in _res.conf).
Ex:
===========================================
<snip>
"reservation-mode": "out-of-pool",
<snip>
"subnet4": [
{
"id": 1,
"subnet": "172.27.12.0/24",
"pools": [ { "pool": "172.27.12.240 - 172.27.12.248" } ],
"option-data": [
{
"name": "routers",
"data": "172.27.12.1"
},
{
"code": 121,
"data": "24, 192, 168, 77, 172, 27, 12, 254, 24, 192,
168, 88, 172, 27, 12, 254, 24, 192, 168, 111, 172, 27, 12, 254, 24,
192, 168, 222, 172, 27, 12, 254"
}
],
<?include "/etc/kea/id1_res.conf"?>
},
{
"id": 2,
"subnet": "192.168.77.0/24",
"pools": [ { "pool": "192.168.77.50 - 192.168.77.55" } ],
"option-data": [
{
"name": "routers",
"data": "192.168.77.254",
"always-send": true
}
],
<?include "/etc/kea/77_id2_res.conf"?>
},
===========================================
On Sat, Aug 3, 2024 at 6:42 AM Ubence Quevedo <[email protected]> wrote:
>
> Looking at this further, I think my problem now has to do with the various
> host reservation options available.
>
> I have a few pools that are in each vlan that are available for anything that
> doesn't have a reservation.
>
> Most everything on my network has reservations for each of the vlans.
>
> The documentation is a little confusing on which option I should be choosing
> with not enough examples.
>
> What I've been looking at:
> https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation
>
> Since my reservations aren't defined in each of the subnets, but rather
> globally, I think I want this configuration:
> {
> "Dhcp4": {
> "reservations-global": true,
> "reservations-in-subnet": false
> }
> }
>
> I have the reservation files split out into json files similar to what the
> older dhcpd allowed to make for a cleaner configuration file:
> "reservations": [
> <?include "/etc/kea/01-dhcp_network.json"?>
> <?include "/etc/kea/02-dhcp_user_systems.json"?>
> <?include "/etc/kea/03-dhcp_ent.json"?>
> <?include "/etc/kea/04-dhcp_servers.json"?>
> <?include "/etc/kea/05-dhcp_iot.json"?>
> ],
>
> Any advice on how to make it so that the host reservation works properly
> without relying on DHCP relay/UDP to give clients the appropriate address?
>
> Or do I already have this configured properly and I have to use a DHCP relay
> to make this work as I'm expecting?
>
> -Ubence
>
> On Sat, Aug 3, 2024 at 2:56 AM Ubence Quevedo <[email protected]> wrote:
>>
>> Turning off the udp dhcp-socket-type and disabling the DHCP relay did work
>> in that my systems were getting IP addresses assigned to them.
>>
>> However, even though I have reservations for just about everything in my
>> network, the systems were getting IP addresses out of scope from their
>> reservations.
>>
>> A system on vlan11 with an IP address of 192.168.11.XXX was getting assigned
>> an address of 192.168.10.XXX.
>>
>> I'll have to dig into the logs to see why this might be, but it could also
>> be because I don't have the firewall rules tightened between the vlans and
>> traffic from one vlan can get to another.
>>
>> Once I set things back to the udp dhcp-socket-type and turned the DHCP relay
>> back on, the systems got the appropriate address.
>>
>> I just assumed that since I had interfaces on each of the vlans that each
>> system on its respective vlan would get its appropriate address.
>>
>> Unless I might have something else misconfigured?
>>
>> -Ubence
>>
>> On Fri, Aug 2, 2024 at 1:18 PM Ubence Quevedo (thatrat) <[email protected]>
>> wrote:
>>>
>>> Yes, here’s the interface-config section that I have defined:
>>> "interfaces-config": {
>>> "interfaces": [
>>> "eno2/192.168.10.3","eno2.11/192.168.11.3","eno2.12/192.168.12.3" ],
>>> "dhcp-socket-type": "udp",
>>> "service-sockets-max-retries": 5,
>>> "service-sockets-retry-wait-time": 5000
>>> },
>>>
>>> …and from further reading on the interfaces-config section, specifically
>>> the dhcp-socket-type configuration:
>>> Using UDP sockets automatically disables the reception of broadcast packets
>>> from directly connected clients. This effectively means that UDP sockets
>>> can be used for relayed traffic only. When using raw sockets, both the
>>> traffic from the directly connected clients and the relayed traffic are
>>> handled.
>>>
>>> So…I’m doing this to myself. 😖
>>>
>>> I’m assuming I should either remove this line or set it to raw, which are
>>> effectively the same thing I believe [I like to have fully qualified
>>> configs when possible to take out the guess work].
>>>
>>> Once I do this though and restart the service, I think I can disable the
>>> relay and then the interfaces should start picking up the traffic.
>>>
>>> -Ubence
>>>
>>> On Aug 2, 2024, at 8:34 AM, Sonic <[email protected]> wrote:
>>>
>>> Are you by chance using:
>>> "dhcp-socket-type": "udp"
>>> for the interfaces in question?
>>>
>>> --
>>> ISC funds the development of this software with paid support subscriptions.
>>> Contact us at https://www.isc.org/contact/ for more information.
>>>
>>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>>>
>>> Kea-users mailing list
>>> [email protected]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>>
>>>
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
