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

Thu Sep 4 13:46:34 UTC 2014

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d1mwpdhcp01-eth0.102-kea-test1.pcap
Type: application/octet-stream
Size: 1076 bytes
Desc: d1mwpdhcp01-eth0.102-kea-test1.pcap
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20140904/f89bb157/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d1mwpdhcp01-eth0.102-kea-test2.pcap
Type: application/octet-stream
Size: 1046 bytes
Desc: d1mwpdhcp01-eth0.102-kea-test2.pcap
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20140904/f89bb157/attachment-0001.obj>