[kea-dev] MySQL host reservations in Github master branch?

Jeffery Harrell sparky at charlietango.com
Mon Jul 25 14:55:30 UTC 2016


Thank you very much!


On July 25, 2016 at 7:54:44 AM, Marcin Siodelski (marcin at isc.org) wrote:

I was able to reproduce your problem on Centos 7. The direct problem
we're hitting is the *unexpected* closure of the connection to the MySQL
database while processing the packet from the client (see the last line
of the pasted log below).

Because the connection gets closed the server doesn't even look into the
database to check for existing reservations.

This may be something specific to MariaDB, which I am also using to
reproduce the issue. I didn't see it with MySQL-community version,
however I may double check.

I am planning to investigate it further, and I'll let you know what I find.

Marcin


2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665] DHCP4_QUERY_DATA
[hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0,
packet details: local_address=192.168.56.2:67,
remote_adress=192.168.56.1:67, msg_type=DHCPDISCOVER (1), transid=0x0,
options:
type=053, len=001: 1 (uint8)
type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8)
6(uint8) 12(uint8)
type=061, len=007: 01:00:0c:01:02:03:04
2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.dhcpsrv/28665]
DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 192.168.56.0/24 for packet
received by matching address 192.168.56.1
2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665]
DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04],
cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 1 was selected
for client assignments
2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665]
DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:04],
cid=[01:00:0c:01:02:03:04], tid=0x0: the selected subnet details:
192.168.56.0/24
2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.dhcpsrv/28665]
HOSTS_CFG_CLOSE_HOST_DATA_SOURCE Closing host data source: mysql


On 18.07.2016 18:26, Jeffery Harrell wrote:
> Fair enough! I’ll keep this on the public list so it might help others.
>
> This morning I tried to create as minimal a lab environment as I could.
> There’s just the DHCP server and one client, both running CentOS 7.2
> with the latest updates. I was able to reproduce the problem. (In fact I
> was unable not to.)
>
> There's a lot of information to share, so I stored most of it in gists.
> I hope that's okay.
>
> Here's my kea.conf file:
>
> https://gist.github.com/jefferyharrell/dcbd9cc40a533bab493ae06ddcbdb1d7
>
> This is the good part:
>
> "subnet4":
> [
>
> {
> "id": 199,
> "subnet": "10.14.199.0/24 <http://10.14.199.0/24>",
> "valid-lifetime": 120,
> "option-data":
> [
> { "name": "routers", "data": "10.14.199.254" }
> ],
> "pools": [
> { "pool": "10.14.199.201 - 10.14.199.249" }
> ]
> }
>
> ]
>
> I tested both with and without the "pools" declaration. With "pools"
> kea-dhcp4 allocates a lease from the pool. Without "pools", kea-dhcp4
> fails to allocate a lease. Also the ludicrously short lease lifetime is
> a testing parameter; I’ve tried this with longer, more plausible
> settings and it made no difference.
>
> Here's the debug log captured during a reboot of the test client.
>
> https://gist.github.com/jefferyharrell/0dc515a2d6a9bf639a5e6f8be03e01eb
>
> This is the good part:
>
> 2016-07-18 11:03:26.980 DEBUG [kea-dhcp4.hosts/4637]
> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C29D4074D,
> found 0 host(s)
> 2016-07-18 11:03:26.980 DEBUG [kea-dhcp4.hosts/4637]
> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet
> id 199 and identifier hwaddr=000C29D4074D
>
> Despite the protestations in the log file, such a host reservation
> really does exist in the database:
>
> https://gist.github.com/jefferyharrell/17261c44930d83be858bb712a6b72a03
>
> So what it looks like to me (I AM NOT A DHCP EXPERT) is that kea-dhcp4
> is simply failing, for one reason or another, to query MySQL for host
> reservations. This is supported by the fact that during the reboot as
> logged above, no MySQL queries were executed by the program.
>
> https://gist.github.com/jefferyharrell/388f8cc282c15b41bfea0accbf9c9f21
>
> (Immediately after I quit kea-dhcp4, which is where the
> close-close-close-quit came from.)
>
> I was thinking maybe this is a build-environment bug, maybe I'm linking
> against a slightly incompatbile version of the MySQL library? But that
> library has been around for ages largely unchanged, so that seemed
> unlikely, plus there would've been an error reported somewhere, I can
> only assume.
>
> Any thoughts?
>
> Thanks so much in advance for your help.
>
>
> On July 18, 2016 at 12:30:24 AM, Marcin Siodelski (marcin at isc.org
> <mailto:marcin at isc.org>) wrote:
>
>> On 17.07.2016 21:24, Jeffery Harrell wrote:
>> > I feel like I’m doing something stupid, but I’ll ask anyway: Is it
>> > possible that MySQL host reservations are currently not working in the
>> > Github master branch?
>> >
>> > I discovered what I think may be a very obscure bug in 1.0.0 having to
>> > do with OFFER replies meant for VMs running on hosts on VLAN trunks
(no
>> > seriously), so I wanted to check the latest version of the project to
>> > see if it’s already been taken care of. I set up a lab system, cloned
>> > the repo and made a build with –with-dhcp-mysql. I set up a new
database
>> > with dhcpdb_create.mysql from Github and inserted a host according to
>> > https://kea.isc.org/wiki/HostReservationsHowTo.
>> >
>> > This test server will happily serve up pool addresses (and will stash
>> > the lease info in MySQL, so the database connection is for-sure
working)
>> > but it completely and obstinately ignores the contents of the hosts
>> > database table. I’ve tried both same-subnet and through-a-relay
clients
>> > and the server claims to be unable to find a host for hardware address
>> > such-and-whatever.
>> >
>> > Here’s the relevant part of my config file:
>> >
>> > |"interfaces-config": { "interfaces": [ "eth0" ], "dhcp-socket-type":
>> > "raw" }, "lease-database": { "type": "mysql", "name": "[REDACTED]",
>> > "host": "[REDACTED]", "user": "[REDACTED]", "password": "[REDACTED]"
},
>> > "hosts-database": { "type": "mysql", "name": "[REDACTED]", "host":
>> > "[REDACTED]", "user": "[REDACTED]", "password": "[REDACTED]" },
>> > "expired-leases-processing": { "reclaim-timer-wait-time": 10,
>> > "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600,
>> > "max-reclaim-leases": 100, "max-reclaim-time": 250,
>> > "unwarned-reclaim-cycles": 5 }, "option-data": [ { "name":
>> > "domain-name-servers", "data": "[REDACTED]" }, { "name":
>> > "domain-search", "data": "[REDACTED]" } ], "valid-lifetime": 3600,
>> > "subnet4": [ { "id": [REDACTED], "subnet": "[REDACTED]/24",
>> > "valid-lifetime": 3600, "option-data": [ { "name": "routers", "data":
>> > "[REDACTED]" } ] } ] |
>> >
>> > And here’s the SQL statement I used to insert the host reservation:
>> >
>> > |INSERT INTO hosts (dhcp_identifier, dhcp_identifier_type,
>> > dhcp4_subnet_id, ipv4_address, hostname) VALUES
>> > (UNHEX(REPLACE('[REDACTED]', ':', '')), (SELECT type FROM
>> > host_identifier_type WHERE name='hw-address'), [REDACTED],
>> > INET_ATON('[REDACTED]'), '[REDACTED]'); |
>> >
>> > Am I doing something wrong?
>> >
>>
>> I don't see any obvious errors in what you're doing. But, since most of
>> the values are "redacted" I can't say if there are any typos in the
>> configuration etc.
>>
>> Host reservations in MySQL should work fine on the latest github
>> version. If the server is unable to find the reservation for a client,
>> I'd think there is some configuration error. Typically, this might be a
>> subnet-id mismatch between the configuration and the value stored in the
>> database, or mismatch in the HW address between the host reservation
>> entry and the client contacting the server. One more thing is that the
>> reserved address can be hijacked by another client at the time when the
>> reservation didn't exist. But, if this is a simple test with only one
>> client, that's rather unlikely.
>>
>> I am willing to assist you in further investigating this issue, but I
>> don't see much I could do without some additional data. Ideally it
>> would be:
>> - The contents of the database, e.g. SELECT * FROM hosts;
>> - The subnet configuration in Kea, including subnet-id
>> - wireshark capture including the communication of this particular
>> client with the server.
>> - Server log on debug level.
>>
>> If this is sensitive information you don't want to post to the list,
>> you're welcome to contact me privately.
>>
>> Thanks for trying out Kea!
>>
>> Marcin Siodeski
>> DHCP Software Engineer,
>> ISC
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20160725/a7fedf58/attachment-0001.html>


More information about the kea-dev mailing list