And what does the logging from kea-dhcp say ?
When there is no logging the client must get the IP from a different DHCP 
server.



Regards


Ronald Blaas


________________________________
From: Kea-users <[email protected]> on behalf of Ubence Quevedo 
<[email protected]>
Sent: Monday, July 29, 2024 13:22
To: Kea user's list <[email protected]>
Subject: Re: [Kea-users] [EXTERNAL] Re: Need to have DHCP Relay in order for 
Kea to work...?

I was able to test this again over the weekend after turning off the listener 
on the Kea DHCP interface on the other DHCP server on my network.  Before 
anyone asks, it's another Ubuntu Linux Kea DHCP server I had setup for the 
older ISC DHCP when I was converting from that to Kea.  The interfaces are on 
multiple VLANs, but in my testing, I had forgotten to turn off the broadcasting 
on my production network.

I turned off the DHCP relay feature on my pfSense system, and tested having a 
client request an address again, and the same thing happened as last time.  The 
server seems to see the broadcast request but doesn't respond.  It's not until 
I turn on the DHCP Relay [at 02:49] that the system gets an IP address.  I did 
capture the interfaces with ip a before turning back on the DHCP Relay, and it 
shows that the interface enp2s0f0 doesn't have an IP address, but after turning 
on the DHCP relay [the second ip a output], it does.

I pulled the following from the leases log I have configured, but I'm not sure 
this will help much since it shows the MAC address of the destination client 
getting the IP address I have reserved for it:
2024-07-27 02:49:13.762 INFO  [kea-dhcp4.leases/3604.130448103573184] 
DHCP4_INIT_REBOOT [hwtype=1 c8:2a:14:45:53:24], cid=[01:c8:2a:14:45:53:24], 
tid=0xcc5b010a: client is in INIT-REBOOT state and requests address 
192.168.11.118
2024-07-27 02:49:13.762 INFO  [kea-dhcp4.leases/3604.130448103573184] 
DHCP4_LEASE_ALLOC [hwtype=1 c8:2a:14:45:53:24], cid=[01:c8:2a:14:45:53:24], 
tid=0xcc5b010a: lease 192.168.11.118 has been allocated for 28800 seconds
2024-07-27 02:49:13.763 INFO  [kea-dhcp4.leases/3604.130448124544704] 
DHCP4_INIT_REBOOT [hwtype=1 c8:2a:14:45:53:24], cid=[01:c8:2a:14:45:53:24], 
tid=0xcc5b010a: client is in INIT-REBOOT state and requests address 
192.168.11.118
2024-07-27 02:49:13.763 INFO  [kea-dhcp4.leases/3604.130448124544704] 
DHCP4_LEASE_ALLOC [hwtype=1 c8:2a:14:45:53:24], cid=[01:c8:2a:14:45:53:24], 
tid=0xcc5b010a: lease 192.168.11.118 has been allocated for 28800 seconds

I did prune out some other system info that was broadcasted from the attached 
logs.

Anything else I can try or other logs to look at as to why this might not be 
working?

-Ubence


On Tue, Jul 23, 2024 at 4:03 AM Ubence Quevedo 
<[email protected]<mailto:[email protected]>> wrote:
Thanks for the response.

I do have another Kea DHCP server on the network, and I thought I only had it 
configured to listen on the interfaces that weren't on the main network, but it 
was configured to listen on all interfaces.

I've changed that, and when I have a chance to test again, I'll retest 
capturing tcpdump packets.

To answer your one question about still not getting an IP, after turning the 
interface off and on, I never see the IP address populate through ifconfig or 
the graphical interface.

I only see it once the DHCP Relay is turned back on.

I'll report back when I'm able to test this again.

-Ubence

On Tue, Jul 23, 2024 at 12:01 AM DDFR | Ronald Blaas 
<[email protected]<mailto:[email protected]>> wrote:
Hi,

From what I am seeing in the tcpdump.
The Client is getting an IP and acknowledge this

Look for the DORA process (Discover -> Offer -> Request -> Ack)
Looking in the dhcp-client_without_relay.txt I am seeing these steps.

So DHCP is working 🙂

How do you conclude that your client did not get an IP ?

As for the tcpdump with relay I did not see the DORA process. Only request and 
ack .

As for the server side tcpdump.. I was expecting to see the same DORA process.
Are there any other DHCP servers in your network? (please check)


Regards

Ronald

________________________________
From: Kea-users 
<[email protected]<mailto:[email protected]>> on 
behalf of Ubence Quevedo <[email protected]<mailto:[email protected]>>
Sent: Monday, July 22, 2024 12:54
To: Kea user's list <[email protected]<mailto:[email protected]>>
Subject: Re: [Kea-users] [EXTERNAL] Re: Need to have DHCP Relay in order for 
Kea to work...?

I tested over the weekend by turning the DHCP Relay off on the pfSense gateway, 
and did a tcpdump on both the client and the server.

I think I'm seeing the broadcasts from the client I was testing on the server, 
and it looks like the client is receiving the response, but the IP isn't 
getting assigned to the system.

This is illustrated in the traffic from dhcp-client_without_relay.txt and 
dhcp-server_without_relay.txt.

As soon as I turned the DHCP Relay back on, the client properly got an IP 
address which is illustrated in dhcp_with_relay.txt.

Maybe I have something misconfigured in my Kea conf?  I'm a bit baffled by this 
since other broadcast traffic is working on my network.

Any thoughts on what I should be looking at next or checking in my Kea conf?

-Ubence


On Fri, Jul 19, 2024 at 4:18 AM Ubence Quevedo 
<[email protected]<mailto:[email protected]>> wrote:
Thanks for the response and the link, it is very helpful.

I'm seeing the DHCP relay traffic I would expect to see.

I'm going to test over the weekend disabling the DHCP relay and see what I see 
then.

-Ubence

On Thu, Jul 18, 2024 at 1:29 AM DDFR | Ronald Blaas 
<[email protected]<mailto:[email protected]>> wrote:
A yes I see.

You are using virtual interfaces.
This should work.

As for relay,  no you do not need relay as the DHCP server is configured inside 
the same network.

Like suggested by others you need to run a tcpdump to see what/if packets are 
received by your dhcp server.

An example would be: tcpdump -i eno2.11 port 67 or port 68 -e -n -vv
(source<https://unixhealthcheck.com/blog?id=433>)

Should be run as root (or sudo)


You should see some traffic from machines requesting DHCP


regards


Ronald Blaas



________________________________
From: Kea-users 
<[email protected]<mailto:[email protected]>> on 
behalf of Ubence Quevedo <[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 17, 2024 13:30
To: Kea user's list <[email protected]<mailto:[email protected]>>
Subject: Re: [Kea-users] [EXTERNAL] Re: Need to have DHCP Relay in order for 
Kea to work...?

U ontvangt niet vaak e-mail van [email protected]<mailto:[email protected]>. 
Meer informatie over waarom dit belangrijk 
is<https://aka.ms/LearnAboutSenderIdentification>
Thanks for the response.

Here are the interfaces configured on the server.  eno2 is the main interface 
[untagged] and then there is eno2.11 and eno2.12 respectively for vlan 11 and 
12:
eno2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.3  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::f604:def0:9990:a797  prefixlen 64  scopeid 0x20<link>
        ether 50:eb:f6:4f:6c:2e  txqueuelen 1000  (Ethernet)
        RX packets 21002000  bytes 4720351435 (4.7 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5775391  bytes 1207246387 (1.2 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0x51200000-51220000

eno2.11: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.11.3  netmask 255.255.255.0  broadcast 192.168.11.255
        inet6 fd19:e769:2155:aa4a:2ca5:722f:5815:fd88  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:8123:1ebe:15d1:88a1  prefixlen 64  scopeid 
0x0<global>
        inet6 fe80::1b5:af43:403b:d5d7  prefixlen 64  scopeid 0x20<link>
        inet6 fd19:e769:2155:aa4a:8997:46a6:a4fc:ddbc  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:83de:c6c8:c181:5dbe  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:596c:3610:d7b4:1d18  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:a2ed:50cf:5609:5e0e  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:bcfe:867f:4dc:c8f8  prefixlen 64  scopeid 
0x0<global>
        inet6 fd19:e769:2155:aa4a:14a6:e870:b2ad:d2d9  prefixlen 64  scopeid 
0x0<global>
        ether 50:eb:f6:4f:6c:2e  txqueuelen 1000  (Ethernet)
        RX packets 5820439  bytes 1191558319 (1.1 GB)
        RX errors 0  dropped 11  overruns 0  frame 0
        TX packets 2733488  bytes 637055127 (637.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno2.12: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.12.3  netmask 255.255.255.0  broadcast 192.168.12.255
        inet6 fe80::fda3:7df7:98b0:d9e6  prefixlen 64  scopeid 0x20<link>
        ether 50:eb:f6:4f:6c:2e  txqueuelen 1000  (Ethernet)
        RX packets 7737728  bytes 1816607005 (1.8 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 529891  bytes 125658614 (125.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

My interfaces in kea-dhcp4.conf are configured like:
"interfaces": [ 
"eno2/192.168.10.3<http://192.168.10.3/>","eno2.11/192.168.11.3<http://192.168.11.3/>","eno2.12/192.168.12.3<http://192.168.12.3/>"
 ]

This is why I'm a little baffled why I need the dhcp relay since all of the 
interfaces should be listening on each vlan but aren't picking up the traffic.

Routing has been an issue on my network, which is related to another post I'm 
going to make later with bridged interfaces and dhcp requests from VMs to those 
bridged interfaces not getting IP addresses even though the server is receiving 
the request but the client isn't acknowledging them for some reason.

-Ubence

On Tue, Jul 16, 2024 at 11:52 PM DDFR | Ronald Blaas 
<[email protected]<mailto:[email protected]>> wrote:
Hi

Not really sure what you mean here: "has one interface that I've setup with 
vlan interfaces"

Like what has been said before, either the DHCP server has an IP address in 
every IP subnet or you will have to make use of DHCP relay.

The DHCP server must know from which network the DHCP request is coming from.

As for logging, if there is nothing in the log you must have a routing problem 
(it is always routing 😋)




Ronald

________________________________
From: Kea-users 
<[email protected]<mailto:[email protected]>> on 
behalf of Ubence Quevedo <[email protected]<mailto:[email protected]>>
Sent: Tuesday, July 16, 2024 13:04
To: Kea user's list <[email protected]<mailto:[email protected]>>
Subject: Re: [Kea-users] [EXTERNAL] Re: Need to have DHCP Relay in order for 
Kea to work...?

U ontvangt niet vaak e-mail van [email protected]<mailto:[email protected]>. 
Meer informatie over waarom dit belangrijk 
is<https://aka.ms/LearnAboutSenderIdentification>
Thanks for all of the responses on this.

The system that is the Kea DHCP server [an Ubuntu system] has one interface 
that I've setup with vlan interfaces.

I can access these other interfaces and verified through nmap that port 67 is 
open on all interfaces.

I can't seem to find any kind of ip helper option in the Unifi Controller 
[v8.2.93 running on a virtual Ubuntu system].

I've reconfigured the DHCP Relay on the pfSense to point to all of the 
interfaces, and I'm now seeing the traffic I'm expecting to see, which is fine 
since. understand a little better of what might be going on.

Just a little confused as to why the broadcast traffic for DHCP requests 
doesn't seem to be picked up on the vlan interfaces on the server.

I do have another question, but I'll put that in a separate post since it 
doesn't seem to be related to this question at hand.

-Ubence

On Mon, Jul 15, 2024 at 6:59 AM Joe Craig 
<[email protected]<mailto:[email protected]>> wrote:

Question about the setup. On the network switches that the DHCP requests would 
hit first, do you have IP Helpers configured? In my experience that’s what I’ve 
had to do to ensure that the packets make it to the DHCP server without a DHCP 
Relay. I’m in an environment where I cannot deploy a DHCP Relay service, so I 
am leveraging the IP Helpers on an L3 switch to forward those requests. This is 
passing through an Cisco firewall and all that. Hope that helps.



Thanks,



Joseph Craig
Systems Engineer
[cid:ii_190df3f001e4cff311]




From: Kea-users 
<[email protected]<mailto:[email protected]>> On 
Behalf Of DDFR | Ronald Blaas
Sent: Monday, July 15, 2024 2:15 AM
To: [email protected]<mailto:[email protected]>
Subject: [EXTERNAL] Re: [Kea-users] Need to have DHCP Relay in order for Kea to 
work...?



You don't often get email from 
[email protected]<mailto:[email protected]>. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>

Not really sure how you have your network setup.



But in my belief, if you want dhcp to work without RELAY you have to make sure 
your DHCP server is directly connected to all the LANs. So your DHCP server 
will need to have multiple Nics.



Is  there a particular reason you do not want to have a dhcp relay?



I have a kinda similar setup and am using DHCP relay. It is operating as 
expected and without problems.



It is also wise to share the output of your log file with the error you are 
receiving.

Tis helps in pinpointing the problem.



Regards





Ronald





________________________________

From: Kea-users 
<[email protected]<mailto:[email protected]>> on 
behalf of Ubence Quevedo <[email protected]<mailto:[email protected]>>
Sent: Monday, July 15, 2024 00:26
To: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Subject: [Kea-users] Need to have DHCP Relay in order for Kea to work...?



U ontvangt niet vaak e-mail van [email protected]<mailto:[email protected]>. 
Meer informatie over waarom dit belangrijk 
is<https://aka.ms/LearnAboutSenderIdentification>

Hi Everyone,



I’ve been using Kea for just under a year for a home setup on a Linux Ubuntu 
server.  I switched from isc dhcp since it was end of life.  My setup has a lot 
of MAC address reservations with some general pools for systems that don’t have 
IP reservations.



I also have a few vlans set up with the reservations for devices on each of the 
vlans.  I’m using pfSense as my gateway with some Unifi equipment that is vlan 
aware.



I’m running into an issue and I’m not sure why and would love some advice on 
how to look into this.



I have the interfaces on the system setup that is running Kea, to advertise on 
the untagged network [mostly some servers], vlan 11 [user systems], and vlan12 
[IoT devices].



I don’t have the firewall in pfSense to block traffic between these networks 
yet, so they can all freely talk to each other.



Even though I have my Kea configured to advertise on all of the interfaces 
[untagged, 11, 12], I can’t seem to get anything to work unless I have the DHCP 
Relay service setup on the pfSense device to redirect all DHCP traffic to the 
Kea system’s untagged IP address [192.168.10.3].



I can verify through nmap that udp port 67 is running on all three interfaces.



If I turn off the DHCP Relay service, I was expecting the interfaces to pick up 
on the DHCP requests from devices on all of these networks.



This doesn’t happen and devices don’t get addresses.  I’ve even watched the 
logs I’ve split out and nothing is written for the duration that the relay 
service is turned off.  As soon as I turn it back on, I start seeing traffic 
again.



I’m running Kea 2.6.0.



I’d love to turn the DHCP Relay off to then try to troubleshoot another issue 
I’m having with bridging interfaces to VMs and then having the VM interface 
assigned to a vlan other than the bridged interface.  It seems to work for 
something else I’m doing, but just trying to rule some things out.  Probably 
another post if I can figure out why the DHCP Relay seems to need to be on.



Any ideas why I need the DHCP Relay service on another device even though all 
of the interfaces on each respective vlan are configured to listen for dhcp 
requests?



-Ubence

--
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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

Reply via email to