[Kea-users] [EXTERNAL] Re: Need to have DHCP Relay in order for Kea to work...?

[Ubence Quevedo]

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 <thatrat at gmail.com> 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) <thatrat at gmail.com>
> 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 <sonicsmith at gmail.com> 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
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240803/868af3d7/attachment.htm>