[Kea-users] Kea 1.1.0, MySQL and client-id
Jeffery Harrell
sparky at charlietango.com
Wed Jan 4 19:56:03 UTC 2017
Thanks for the suggestion, Marcin. No luck though. I haven’t yet had the
opportunity to really systematically go through my configuration to look
for the fault, but here’s what I can tell you so far:
I added the client-id host identifier type to my MySQL database. I believe
I did this correctly.
MariaDB [kea]> SELECT * FROM host_identifier_type;
+------+------------+
| type | name |
+------+------------+
| 0 | hw-address |
| 1 | duid |
| 2 | circuit-id |
| 3 | client-id |
+------+------------+
4 rows in set (0.00 sec)
I set “host-reservation-identifiers” to “auto” in the Dhcp4 section of
kea.conf as you suggested. (Everything that follows is the same as what I
get if I set it to “auto” or to any combination of “hw-address” and
“client-id” with or without other tokens. If I JUST set it to “hw-address”
then Kea doesn’t bother trying to look up host reservations by client ID,
which is exactly what I’d expect.)
Then I created a host reservation with a client ID. The reservation looks
like this:
MariaDB [kea]> SELECT * FROM hosts WHERE host_id=272 \G
*************************** 1. row ***************************
host_id: 272
dhcp_identifier: milo
dhcp_identifier_type: 3
dhcp4_subnet_id: 168715520
dhcp6_subnet_id: NULL
ipv4_address: 168715522
hostname: milo.dallas.charlietango.com
dhcp4_client_classes: NULL
dhcp6_client_classes: NULL
dhcp4_next_server: NULL
dhcp4_server_hostname: NULL
dhcp4_boot_file_name: NULL
The dhcp_identifier looks like plain text but it was created in what I
assume is the proper way, by passing MySQL a hex representation of a
sequence of bytes with the UNHEX function. I think it’s right and proper.
MariaDB [kea]> SELECT HEX(dhcp_identifier) FROM hosts WHERE host_id=272;
+----------------------+
| HEX(dhcp_identifier) |
+----------------------+
| 6D696C6F |
+----------------------+
Here’s the relevant debug log output from an attempt to get a DHCP lease
using this client ID. I tested from a Linux VM with the command line
“dhclient -I milo -v.” It’s worth pointing out there’s a DHCP-relaying
router between the client and the server, but I see the same results when
there’s no router in the way.
2017-01-04 13:34:00.731 DEBUG [kea-dhcp4.packets/4117]
DHCP4_BUFFER_RECEIVED received buffer from 10.14.99.254:68 to 10.14.99.23:67
over interface ens192
2017-01-04 13:34:00.731 DEBUG [kea-dhcp4.options/4117] DHCP4_BUFFER_UNPACK
parsing buffer received from 10.14.99.254 to 10.14.99.23 over interface
ens192
2017-01-04 13:34:00.731 DEBUG [kea-dhcp4.packets/4117]
DHCP4_PACKET_RECEIVED [hwtype=1 00:50:56:bc:89:97], cid=[6d:69:6c:6f],
tid=0xd70f580e: DHCPDISCOVER (type 1) received from 10.14.99.254 to
10.14.99.23 on interface ens192
That’s both the correct MAC address and the correct client ID in
hexadecimal. The IP 10.14.99.254 is the IP of the DHCP server’s side of the
relaying router, and 10.14.99.23 is the IP of the DHCP server.
2017-01-04 13:34:00.731 DEBUG [kea-dhcp4.packets/4117] DHCP4_QUERY_DATA
[hwtype=1 00:50:56:bc:89:97], cid=[6d:69:6c:6f], tid=0xd70f580e, packet
details: local_address=10.14.99.23:67, remote_adress=10.14.99.254:68,
msg_type=DHCPDISCOVER (1), transid=0xd70f580e,
options:
type=050, len=004: 10.14.101.2 (ipv4-address)
type=053, len=001: 1 (uint8)
type=055, len=013: 1(uint8) 28(uint8) 2(uint8) 121(uint8) 15(uint8)
6(uint8) 12(uint8) 40(uint8) 41(uint8) 42(uint8) 26(uint8) 119(uint8)
3(uint8)
type=061, len=004: 6d:69:6c:6f
Here we see Kea seems to properly decode option 61. I think.
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.dhcpsrv/4117]
DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.14.101.0/24 for packet
received by matching address 10.14.101.254
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.packets/4117]
DHCP4_SUBNET_SELECTED [hwtype=1 00:50:56:bc:89:97], cid=[6d:69:6c:6f],
tid=0xd70f580e: the subnet with ID 168715520 was selected for client
assignments
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.packets/4117] DHCP4_SUBNET_DATA
[hwtype=1 00:50:56:bc:89:97], cid=[6d:69:6c:6f], tid=0xd70f580e: the
selected subnet details: 10.14.101.0/24
This is all correct, based on the giaddr from the relaying router, I’m
assuming.
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation
for subnet id 168715520, identified by hwaddr=005056BC8997
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
identifier: hwaddr=005056BC8997
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=005056BC8997,
found 0 host(s)
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id
168715520 and identifier hwaddr=005056BC8997
I assume these are all reports that Kea is trying to look up a host
reservation using the MAC address. There is no such host reservation in the
database so it’s proper that these should fail.
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation
for subnet id 168715520, identified by client-id=6D696C6F
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
identifier: client-id=6D696C6F
2017-01-04 13:34:00.732 DEBUG [kea-dhcp4.hosts/4117]
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=6D696C6F,
found 0 host(s)
I would have expected that to succeed, though. There IS a reservation with
that subnet ID and that client ID … at least I think there is.
Am I not encoding the client ID correctly in the database? That’s the only
thing I can think of that would be throwing this off. I’ve tried
(superficially) looking at the MySQL query log, but it’s not very helpful
because Kea uses prepared statements that MySQL doesn’t seem to log by
default, or something like that. I haven’t figured it out yet.
On January 4, 2017 at 11:17:48 AM, Marcin Siodelski (marcin at isc.org) wrote:
Jeffery,
I think I found the flaw in Kea which may result in behavior you're
observing. Thankfully, I also have a good guess how to work around this
problem.
Can you please try adding the following parameter to your DHCPv4 server
configuration:
"host-reservation-identifiers": [ "auto" ]
?
Other values should also work:
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
"client-id" ],
OR
"host-reservation-identifiers": [ "client-id" ],
Marcin
On 03.01.2017 18:57, Jeffery Harrell wrote:
> Hi, Marcin. Thanks for the reply. I did try inserting the missing row
> into our MySQL database. I also tried setting up an isolated test
> environment this morning using PostgreSQL 9.5 as the backend but
> client-id reservations weren't working for me there either, so it seems
> pretty obvious that I'm doing something wrong. MAC address-based
> reservations work like a charm, but if I try to get Kea to give me a
> lease based on a client id reservation in a subnet with a pool, it gives
> me an IP from the pool, and if I try to get one out of a subnet with no
> pool it just doesn't give a lease at all.
>
> Like I said, it seems to me to be a configuration problem on my end. I'm
> going to try to go through things very systematically following the
> documentation carefully to see if I can find my error.
>
> On Tue, Jan 3, 2017 at 1:05 AM, Marcin Siodelski <marcin at isc.org
> <mailto:marcin at isc.org>> wrote:
>
> On 03.01.2017 03:55, Jeffery Harrell wrote:
> > I hope this isn’t a frequently asked question or anything; I’ve
> searched
> > and searched. Is it a known issue that client-id-based host
> reservations
> > aren’t currently working using the MySQL backend? I ask because (A) I
> > can’t seem to get one to work in my environment, which may well be my
> > fault, but (B)
> > comparing /usr/share/kea/scripts/mysql/dhcpdb_create.mysql
> > and /usr/share/kea/scripts/pgsql/dhcpdb_create.pgsql I see that the
> > contents of host_identifier_type aren’t the same. The Postgres
> version has
> >
> > INSERT INTO host_identifier_type VALUES (3, 'client-id’);
> >
> > while the MySQL version stops at #2, circuit-id. This makes me
> wonder if
> > client-id host reservations aren’t supposed to be working with the
> MySQL
> > backend right now? I thought maybe I’d ask to see if there was a quick
> > answer that could save me more hours of fiddling around and trying to
> > read the source code.
> >
> > Again, apologies if I’m treading on old ground. Thanks!
> >
> >
>
> Hello Jeffery,
>
> It seems to be a bug in our MySQL database creation scripts. The
> host_identifier_type table should include 'client-id' entry. Other than
> that, the 'client-id' based reservations should work for MySQL.
>
> Did you try yo insert the dhcp_identifier_type of 3 into the hosts table
> for your reservation?
>
> Marcin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170104/59a0fbed/attachment.htm>
More information about the Kea-users
mailing list