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

[Jeffery Harrell]

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",
        "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) 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/20160718/0878324d/attachment.html>