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
