[kea-dev] MySQL host reservations in Github master branch?
Marcin Siodelski
marcin at isc.org
Tue Jul 26 04:08:03 UTC 2016
I'am glad it works. Thanks for testing. I will put the patch into the
repo soon.
On 26.07.2016 01:52, Jeffery Harrell wrote:
> 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
> <mailto: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>
> > > <mailto: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> <http://192.168.56.2:67>,
> > > > remote_adress=192.168.56.1:67 <http://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>
> > > > <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> <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>
> > <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>>
> > > > > <mailto: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
> > > > >>
> > > > >>
> > > > >>
> > > >
> >
More information about the kea-dev
mailing list