Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: duplicate leases error (Marcin Siodelski)
2. Re: memfile / loading of expired leases on startup
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Oct 2016 14:39:28 +0200
From: Marcin Siodelski <[email protected]>
To: [email protected], kea-dev <[email protected]>
Subject: Re: [kea-dev] duplicate leases error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 04.08.2016 15:25, Jan Dvo??k wrote:
> We are seeing "error during attempt to allocate an IPv4 address:
> multiple records were found in the database where only one was expected
> for query get_lease4_hwaddr_subid" errors for hosts after they come up
> the first time after network provisioning.
>
> Basically, hosts get one lease for BIOS, second lease for the installer
> and when they come up finally, KEA refuses to give them either. For now,
> we have hacked this by a pre-INSERT trigger that removes any (subnet_id,
> hwaddr)-unique leases prior to inserting a new one.
>
> Please advise.
>
>
Jan,
Many thanks for your message, which apparently got buried on the kea-dev
list, and has never been replied.
I see how that can be the case that the server refuses to allocate the
lease as a result of detecting that there is already more than one lease
associated with a given MAC address, and it is indeed wrong behavior of
the server.
I think this is what your description says, but I'd like to double check....
The BIOS shows up as a client-id0/hw-address identity. It gets the
lease. The installer shows up as client-id1/hw-address and gets the
lease just fine. The client-id0 is different than client-id1 and
hw-address is the same in both cases.
Finally, the host comes up as client-id2/hw-address and the server finds
that even though there is no lease for client-id2, there are two leases
for hw-address and it refuses to allocate the lease, i.e. sends DHCPNAK.
Is this correct?
Marcin Siodelski
ISC
------------------------------
Message: 2
Date: Tue, 4 Oct 2016 13:16:07 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] memfile / loading of expired leases on startup
Message-ID:
<ab94b0b675bdf14189cd5a861db36c845a511...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
> On 15.09.2016 17:09, Chaigneau, Nicolas wrote:
> > Hello,
> >
> >
> >
> > Following ticket #4294 that you've fixed in 1.1.0-beta (thanks again!),
> > there is another related issue I'd like to discuss.
> >
> > Upon startup, leases (using memfile) are loaded from disk, even if they are
> > expired.
> > So if Kea is shut down for maintenance for example, and restarted after all
> > the leases are expired, they are loaded anyway. This entails that the
> > reclaim mechanism will have to catch up, and depending on configuration
> > this can take quite a long time.
> >
> > This causes two issues:
> > - Until the reclaim mechanism has finally caught up, the statistics will
> > not be accurate.
> > - And this is lots of unnecessary work for this mechanism (hence for Kea),
> > that could be avoided.
> >
> > Proposed evolution: upon startup, when loading leases from disk, check if a
> > given lease is expired. If so... don't load it.
> >
> > Well, it's probably slightly more complicated than that. With lease
> > affinity, maybe something like:
> >
> > If <lease expiry> + hold-reclaimed-time > now : then load this lease
> > If not, then just ignore this lease.
> >
> >
> >
> > Thoughts ?
> >
> >
>
> Nicolas,
>
> Once again, sorry for the delays in responding to your post. It's been busy
> time for us.
No worries at all.
I was just confused at not seeing anything on the list. Turns out it is just
very low traffic when no dev is around.
>
> There are different ways of looking at the issue you have raised. There are a
> couple of things that happen when a lease is expired and
> reclaimed: DDNS, hooks invocation, database updates and finally statistics.
> From what you're saying, it seems that in your use case you just want to
> "forget" the expired leases after temporary down time of the server. But, in
> a general case, people may want to take actions upon expired leases even
> after the temporary downtime of the server. What about the case when the
> server crashed for any reason and has been brought up back? The short
> interruption of the server shouldn't cause us to not clean up DNS, and/or
> execute hooks? Or it should? It may depend on the use case. Say... you've had
> a server running for a while and you shut it down for a day. Maybe after a
> day it doesn't make sense to perform lease expirations? Or it does?
>
> We took a "safe" approach to not make any assumptions. We load whatever have
> been in the lease database prior to server shut down and let the server deal
> with this situation using lease expiration mechanisms. Now, I suppose we
> could maybe perform lease reclamation while leases are loaded from a file
> (and while the server is starting up) but that would rather delay the startup
> of your server because not only would you have to load leases from file but
> also reclaim them.
Thanks for the explanation, that makes sense. I can see now that my suggestion
was naively simplistic :)
Delaying the server startup is not a good idea, I agree. It can already take
quite some time if there are lots of leases to load.
>
> On the other hand, maybe it is worth considering to add a configuration flag
> to disable reclamation of leases on startup when the specific use case
> doesn't need reclamation?
It would certainly be useful to me.
As you guessed, in my case I don't have anything (DNS or hooks) that I need to
handle on lease reclamation.
Currently I have a patch to do just that (without the configurability), but
ultimately I'd like to get rid of it (that's the last remaining patch I need
now, with Kea 1.1.0) so I can deploy Kea "out of the box".
I'll open a ticket for the suggestion.
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 31, Issue 3
**************************************
