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

Jeffery Harrell sparky at charlietango.com
Mon Jul 25 23:52:13 UTC 2016


This was a super-easy test. I can confirm that your patch fixes the problem
in my environment. Without your patch, kea-dhcp4 failed to find host
reservations in MariaDB. With it, it finds the reservations no problem,
just like 1.0.0 does. Thank you very, very much.


On July 25, 2016 at 9:33:18 AM, Marcin Siodelski (marcin at isc.org) wrote:

I attached a patch for the issue which, I believe, should resolve your
problem. Can you please verify that it works?

Please do:
$ git apply 0001-master-Recreate-HostMgr-after-re-configuration.patch

and then recompile and reinstall Kea. It doesn't have to be clean rebuild.

I also created Kea ticket: http://kea.isc.org/ticket/4544 to track this
problem.

Marcin



On 25.07.2016 16:55, Jeffery Harrell wrote:
> Thank you very much!
>
>
> On July 25, 2016 at 7:54:44 AM, Marcin Siodelski (marcin at isc.org
> <mailto: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 <http://192.168.56.2:67>,
> > remote_adress=192.168.56.1:67 <http://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
> > <http://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 <http://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> <
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>
> > > <mailto: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/540020e3/attachment-0001.html>


More information about the kea-dev mailing list