[Kea-users] Reservations not being assigned

Tue Aug 16 14:38:22 UTC 2016

Can you run a TCPDUMP and past 10-20 lines in this thread?

tcpdump -i <interface-name> port 67 or port 68 -n -e

Todd Simmons
CCIE Wireless #42411
Network Consulting Engineer
Advanced Services WWWP - Wireless LAN
Cisco Systems, Inc.
todsimmo at cisco.com
Phone: +1 469 255 0183
Mobile: +1 512 749 7167

Cisco.com <http://cisco.com/> - http://www.cisco.com
<http://www.cisco.com/>

http://wwwin-tools.cisco.com/dir/vcard/todsimmo.vcf

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender by
reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

On 8/16/16, 7:32 AM, "Kea-users on behalf of Marcin Siodelski"
<kea-users-bounces at lists.isc.org on behalf of marcin at isc.org> wrote:

>On 05.08.2016 21:40, Matthew Pounsett wrote:
>> I have what I think is a fairly straightforward config, but I'm having
>> issues with it.  From the default kea.conf that ships with FreeBSD ports
>> I have made the following changes:
>> 1) listen on all interfaces
>> 2) add global dns servers options
>> 3) added two subnets:
>>    3a) an RFC1918 /24
>>     - subnet specific option for a router
>>     - one pool of 10.0.5.100 to 10.0.5.254
>>     - several out-of-pool reservations (none in-pool)
>>    3b) a routed /28
>>     - subnet specific option for a router
>>     - no pools
>>     - several reservations
>> 
>> 
>> 3b works fine.  Neither the pool nor the reservations in 3a seem to be
>> working.  For any of those, kea seems to be giving up before even
>> attempting to make an assignment:
>> 2016-08-05 15:04:31.959 WARN  [kea-dhcp4.alloc-engine/1223]
>> ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 0c:c4:7a:b9:24:91],
>> cid=[01:0c:c4:7a:b9:24:91], tid=0xfc7cd269: failed to allocate an IPv4
>> address after 0 attempt(s)
>> 
>> The server running Kea has addresses on its interface in both subnets.
>> 
>> I have triple-checked that the subnet 'name', pool, and reservations are
>> all out of the same /24
>> 
>> When I turn on debugging, it looks like kea is ignoring the available
>> pool in 3a, and is trying to assign addresses out of 3b instead:
>> 
>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108]
>> DHCP4_SUBNET_SELECTED [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: the subnet with ID 2
>> was selected for client assignments
>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108] DHCP4_SUBNET_DATA
>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>> tid=0xae5b3aa3: the selected subnet details: 216.235.10.32/28
>> <http://216.235.10.32/28>
>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108]
>> DHCP4_PACKET_RECEIVED [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: DHCPDISCOVER (type 1)
>> received from 0.0.0.0 to 255.255.255.255 on interface em0
>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108] DHCP4_QUERY_DATA
>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>> tid=0xae5b3aa3, packet details: local_address=255.255.255.255:67
>> <http://255.255.255.255:67>, remote_adress=0.0.0.0:68
>> <http://0.0.0.0:68>, msg_type=DHCPDISCOVER (1), transid=0xae5b3aa3,
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.packets/2108]
>> DHCP4_SUBNET_SELECTED [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: the subnet with ID 2
>> was selected for client assignments
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.packets/2108] DHCP4_SUBNET_DATA
>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>> tid=0xae5b3aa3: the selected subnet details: 216.235.10.32/28
>> <http://216.235.10.32/28>
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID get one host with IPv4
>> reservation for subnet id 2, HWADDR hwtype=1 08:00:27:2c:73:00, DUID
>> 70:6f:75:64:72:69:65:72:65
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>> HOSTS_CFG_GET_ALL_HWADDR_DUID get all hosts with reservations for HWADDR
>> hwtype=1 08:00:27:2c:73:00 and DUID 70:6f:75:64:72:69:65:72:65
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
>> identifier: hwaddr=08:00:27:2c:73:00
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
>> hwaddr=08:00:27:2c:73:00, found 0 host(s)
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_NULL host not found using subnet
>> id 2, HW address hwtype=1 08:00:27:2c:73:00 and DUID
>> 70:6f:75:64:72:69:65:72:65
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.ddns/2108]
>> DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: processing client's
>> Hostname option
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.ddns/2108]
>> DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: client sent Hostname
>> option: poudriere
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.dhcpsrv/2108]
>> DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID 2
>> and hardware address hwtype=1 08:00:27:2c:73:00
>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.alloc-engine/2108]
>> ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new
>> lease to the client [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3
>> 2016-08-05 15:37:21.719 WARN  [kea-dhcp4.alloc-engine/2108]
>> ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 08:00:27:2c:73:00],
>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: failed to allocate an
>> IPv4 address after 0 attempt(s)
>> 
>> Any suggestions on how to approach troubleshooting this?
>> 
>> % kea-dhcp4 -V
>> 1.0.0
>> tarball
>> linked with:
>> log4plus 1.1.2
>> OpenSSL 0.9.8zh-freebsd 3 Dec 2015
>> database:
>> PostgreSQL backend 2.0, library 90313
>> Memfile backend 2.0
>> 
>> 
>> 
>
>Hi Matthew,
>
>When dealing with non-relayed (direct traffic), the only parameters that
>the server can use to select the subnet are: client's source address,
>ciaddr, IP address assigned to the interface on which the server
>received the packet. In case this is a new allocation, none of the first
>two is available for the server. Thus, the server will use the local IP
>address assigned to the interface on which it has received the packet to
>select the subnet. If that address happens to be the one that matches
>subnet with ID 2, it will pick this subnet. Since, there are no pools,
>it will fail to allocate any address. Also, because static reservations
>are made for another (non-selected) subnet, it will not use those
>reservations.
>
>Do you serve both subnets on the same physical interface?
>
>Marcin Siodelski
>ISC
>
>_______________________________________________
>Kea-users mailing list
>Kea-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/kea-users