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

[Chaigneau, Nicolas]

Thanks for the explanation.

To answer your question: yes, this is a real configuration.
We have a DHCP dedicated host with a single interface and multiple IP addresses, which are used by gateways to select leases from different subnets.

Currently we handle this with multiple dhcpd instances, but the goal is to replace them with a single Kea server.


Nicolas.



> 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


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.