[Kea-users] kea dhcp4 - configuration of local listening IP addr ?

Thu Sep 4 15:41:19 UTC 2014

Kea uses raw sockets to receive and send DHCPv4 messages. This is
required to support directly connected clients which don't have an
address yet. The raw socket is bound to the device/interface, not to the
specific IPv4 address. As a result, Kea receives all packets which show
up on this interface. If you have more than one address on this
interface the socket which is supposed to receive unicast packets to one
of the addresses also receives packets unicast to other addresses.

That's why Kea receives unicast packets from the relay even though they
are sent to another IP address.

Part of the problem is that we never really got round to implementing
support for multiple IPv4 addresses assigned to the same interface and
thus we don't have selection of addresses on which the server should
listen (previous issue we discussed) and also raw sockets don't filter
out packets sent to other unicast addresses because there is an implicit
assumption that there is only one address.

With BPF it is possible to filter out unwanted packets and we will have
to extend the BPF program to remove these packets at the system kernel
level. I think it is going to be a straight forward change.

Here is a ticket that I just created: http://kea.isc.org/ticket/3547

Regarding the other issue, with two DHCPOFFERs having different offered
addresses. The reason for this behavior is the way that our address
allocation engine works. When it issues an Offer it bumps up the next
address to be Offered. So, if it receives a DHCPDISCOVER on one socket
it will send DHCPOFFER with the next available address. Then, it will
receive DHCPDISCOVER on the other socket and will treat it as a separate
request (it doesn't matter that it is the same client). That way
allocation engine will avoid offering the same address twice. When the
client sends DHCPREQUEST it will ask for the offered address and will
get it.

Question for you. Do you have any use case in mind whereby there may be
more than one addresses on the particular interface and the DHCP server
is listening on both of them? Do you think it should be legal from the
configuration standpoint?

Marcin

On 04/09/14 15:46, Chaigneau, Nicolas wrote:
> 
>> Thanks again for spending your time on testing Kea. Please see my answers inline.
> 
> 
> No problem. Thanks for listening and helping :)
> 
> 
>> Yes, this use case requires additional configuration parameter to specify what address on the interface the server should listen.
> Currently, Kea configuration doesn't provide this parameter and it creates sockets for all addresses regardless if this is the same or different interface. I > will submit a ticket for this feature.
> 
> 
> Thank you.
> 
> 
>> I think we could use similar notation to restrict the DHCPv4 server to listen on selected IPv4 addresses:
>>
>> "interfaces": [ "eth0/10.1.2.3" ]
> 
> 
> Seems good to me.
> 
> 
> Additionally, this could be useful also in subnet scope, so we can restrict a subnet based on the interface and destination IP address of received packet. This would be in addition to existing parameter "relay"/"ip address", and would offer more flexibility in configuration.
> 
> This would allow a relay, using the same giaddr, to send packets to distinct IP addresses, in order to get leases from distinct subnets.
> 
> For example:
> 
> 	"subnet4": [
> 		{
> 			"subnet": "10.228.0.0/16",
> 			"pools": [ { "pool": "10.228.0.2 - 10.228.255.254" } ],
> 			"relay": {
> 				"ip-address": "10.163.216.251",
> # proposed evolution:
> 				"interface": "eth0.102/10.163.216.229"
> # or maybe just:
> 				"local-ip-address": "10.163.216.229"
> 			},
> 		},
> 	]
> 
> 
>>>  
>>>
>>> Then, if a DHCP message is sent by a relay to dhcpd local IP addr, two 
>>> responses are sent back: both dhcpd and kea manage to answer! (even 
>>> though kea couldn't bind to this IP address, apparently the interface 
>>> is
>>> enough)
>>
>> Hm, is there any other interface that Kea is listening on and can receive relayed messages?
>>
>> Would it be possible to get the traffic capture that shows this behavior?
> 
> 
> There are other interfaces on server host, but only one (eth0.102) is defined in kea configuration.
> Here's an extract of the log:
> 
> 2014-09-04 15:28:08.064 DEBUG [kea-dhcp4.dhcpsrv/7843] DHCPSRV_CFGMGR_CLEAR_ACTIVE_IFACES stop listening on all interfaces
> 2014-09-04 15:28:08.064 DEBUG [kea-dhcp4.dhcpsrv/7843] DHCPSRV_CFGMGR_ADD_IFACE adding listening interface eth0.102
> 2014-09-04 15:28:08.064 INFO  [kea-dhcp4.dhcp4/7843] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration:
> 2014-09-04 15:28:08.064 DEBUG [kea-dhcp4.dhcp4/7843] DHCP4_DEACTIVATE_INTERFACE deactivate interface eth0
> 2014-09-04 15:28:08.064 DEBUG [kea-dhcp4.dhcp4/7843] DHCP4_DEACTIVATE_INTERFACE deactivate interface eth0.201
> 2014-09-04 15:28:08.064 INFO  [kea-dhcp4.dhcp4/7843] DHCP4_ACTIVATE_INTERFACE activating interface eth0.102/6
> 2014-09-04 15:28:08.072 WARN  [kea-dhcp4.dhcp4/7843] DHCP4_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface eth0.102, reason: failed to bind fallback socket to address 10.163.216.229, port 67, reason: Address already in use - is another DHCP server running?
> 
> Kea is configured with one interface only (eth0.102). This interface has two IP addresses (10.163.216.228 and 10.163.216.229).
> Dhcpd is started first, and binds to one IP (10.163.216.229).
> Kea is started second, tries to bind to both addresses, but only succeeds with 10.163.216.228.
> A Discover is sent by a relay to 10.162.216.229 ("owned" by dhcpd).
> Both dhcpd and kea offer a lease in return. See capture "d1mwpdhcp01-eth0.102-kea-test1.pcap" attached.
> 
> Also, we can see in Kea debug log that it receives the Offer sent by dhcpd (which is strange, since this is unicast):
> 	2014-09-04 15:08:58.190 DEBUG [kea-dhcp4.dhcp4/7802] DHCP4_UNSUPPORTED_RCVD_PACKET_TYPE received message (transaction id 2), having type 235081550 is not supported
> (also note that there is a minor bug in this debug log: arguments are in the wrong order).
> 
> 
> Another scenario which might be of interest to you:
> Kea is configured with one interface only (eth0.102). This interface has two IP addresses (10.163.216.228 and 10.163.216.229).
> (same as before)
> Kea is started alone (no dhcpd), binds to both addresses.
> A Discover is sent by a relay to 10.162.216.228 (but the same thing happens with the other IP address).
> Kea offers two distinct leases in return. See capture "d1mwpdhcp01-eth0.102-kea-test2.pcap" attached.
> 
> Also, in Kea debug log we see two "DHCP4_UNSUPPORTED_RCVD_PACKET_TYPE" debug messages:
> 	2014-09-04 15:21:45.045 DEBUG [kea-dhcp4.dhcp4/7818] DHCP4_UNSUPPORTED_RCVD_PACKET_TYPE received message (transaction id 2), having type 2114414715 is not supported
> 	2014-09-04 15:21:45.046 DEBUG [kea-dhcp4.dhcp4/7818] DHCP4_UNSUPPORTED_RCVD_PACKET_TYPE received message (transaction id 2), having type 2114414715 is not supported
> 
> 
> 
> Regards,
> Nicolas.
> 
> 
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
> 