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: Malformed packets returned by Kea (Chaigneau, Nicolas)
2. Re: Malformed packets returned by Kea (Marcin Siodelski)
3. Lease File Cleanup in Kea - Design Document (Marcin Siodelski)
4. Re: Lease File Cleanup in Kea - Design Document
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Jan 2015 15:15:00 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Malformed packets returned by Kea
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194c5...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
Are you sure about this ?
This doesn't seem to work, I have the following error on startup:
ERROR [kea-dhcp4.dhcp4/12272] DHCP4_CONFIG_LOAD_FAIL configuration
error using file: /mnt/wifi/users/NCH/pcap/prod/kea-c1-replay.conf, reason:
Failed to select interface: unicast addresses in the format of:
iface-name/unicast-addr_stress can only be specified for IPv6 addr_stress family
Or maybe this isn't available on the GitHub repository yet ?
Regards,
Nicolas.
> Oh, I forgot to mention that with the latest Kea version you have the ability
> to select an IPv4 address on the interface with multiple addresses, on which
> you want Kea to listen. However, it still lacks the ability to filter out the
> unicast packets sent to a different address as described in #3547.
>
> Anyway, I recall you were after this feature, so you might want to test it.
>
> Marcin
>
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.
------------------------------
Message: 2
Date: Mon, 05 Jan 2015 16:22:32 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Malformed packets returned by Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I updated the master branch on github. Please try again.
Marcin
On 05/01/15 16:15, Chaigneau, Nicolas wrote:
>
> Are you sure about this ?
>
> This doesn't seem to work, I have the following error on startup:
>
>
> ERROR [kea-dhcp4.dhcp4/12272] DHCP4_CONFIG_LOAD_FAIL configuration
> error using file: /mnt/wifi/users/NCH/pcap/prod/kea-c1-replay.conf, reason:
> Failed to select interface: unicast addresses in the format of:
> iface-name/unicast-addr_stress can only be specified for IPv6 addr_stress
> family
>
>
> Or maybe this isn't available on the GitHub repository yet ?
>
>
> Regards,
> Nicolas.
>
>
>> Oh, I forgot to mention that with the latest Kea version you have the
>> ability to select an IPv4 address on the interface with multiple addresses,
>> on which you want Kea to listen. However, it still lacks the ability to
>> filter out the unicast packets sent to a different address as described in
>> #3547.
>>
>> Anyway, I recall you were after this feature, so you might want to test it.
>>
>> Marcin
>>
> 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.
>
------------------------------
Message: 3
Date: Mon, 05 Jan 2015 16:31:14 +0100
From: Marcin Siodelski <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
Following the thread regarding the requirements for Lease File Cleanup
in Kea
(https://lists.isc.org/pipermail/kea-dev/2014-December/000211.html), I
have created a short design document for this feature:
http://kea.isc.org/wiki/LFCDesign
I have to admit that I was in rush preparing the document, so please
forgive me if anything is underspecified or unclear. I will be happy to
clarify if you point out the specific paragraphs that should be made
clearer.
The last section of this document proposes the split of implementation
into actual tickets. It goes along with the initial estimates for the
implementation work (specified in days).
Please review as soon as possible because we need to incorporate this in
our release schedule this week.
Thanks,
Marcin
------------------------------
Message: 4
Date: Tue, 6 Jan 2015 10:41:37 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, Kea Dev List
<[email protected]>
Subject: Re: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194c5...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello Marcin,
Thanks for sharing this design document.
You'll find my comments hereafter.
Regards,
Nicolas.
1) about the clean-up algorithm
> The cleanup of any file by the kea-lfc is achieved by removing lease entries
> which have expired, i.e. "expired" field holds the time later than the
> current time minus an arbitrary value to account for a possible positive time
> skew.
>From what I understand of this, the LFC will simply keep lines for which the
>"expired" field is not reached yet (and remove the others), regardless of the
>lease actual status.
This implies that:
- If for a given lease, a DHCP Release has been processed, only the related
entry in the file is cleaned up. Other entries (related to the initial request,
and renew - if any) associated to this given lease are maintained until they
also expire, even though there is no such lease anymore.
- If a client sends renews, they will all be kept until they individually
expire. For a typical renew-timer set to half of lease duration, this means
that for an active lease there will be two entries in the lease file. Also,
faulty devices may send many renews, in which case we would have as many non
expired entries for the same lease.
Is that correct ?
>From the requirements page, I understood that all redundant entries would be
>removed.
To achieve this I believe you would need to keep in memory the list (maybe as a
hash ?) of active leases along with their expiration time, which you would
update while parsing <previous lease file> and <lease file copy>. Only when the
parsing is complete could <LFC output file> be created.
This would also address the issue you noted in the case of a crash between
renaming <LFC output file> and deleting <lease file copy>.
That said, I'm not sure this is really indispensable. The proposed algorithm
ensures that all redundant information will eventually be cleaned up. This may
take a while though, depending on the configured lease time. In my case I plan
to have a relatively short lease time so that would probably not be too much of
an issue.
If it's too complicated to handle, maybe this could be implemented in an
ulterior version of LFC ?
(would that be complicated ? I guess Kea will have to read the two files anyway
so it can populate its lease backend. Maybe this is reusable for kea-lfc ?)
2) about kea-lfc usage
> kea-lfc [-4|-6] -p <previous-lease-file-name> -i <lfc-input-lease-file-name>
> -o <output-file-name> -c <kea-configuration-file>
The example allows to specify the three file names.
However according to "how the name is constructed", I believe these are not
necessary, since they are automatically constructed by Kea (from the actual
lease file name).
Moreso, it is required for "output" and "previous" files to be on the same
filesystem (otherwise the rename would be a copy).
Consequently, only <kea-configuration-file> seems necessary to me. It allows to
get the actual lease file name, and derive the name of the related lease files.
> Hi,
>
> Following the thread regarding the requirements for Lease File Cleanup in Kea
> (https://lists.isc.org/pipermail/kea-dev/2014-December/000211.html), I have
> created a short design document for this feature:
>
> http://kea.isc.org/wiki/LFCDesign
>
> I have to admit that I was in rush preparing the document, so please forgive
> me if anything is underspecified or unclear. I will be happy to clarify if
> you point out the specific paragraphs that should be made clearer.
>
> The last section of this document proposes the split of implementation into
> actual tickets. It goes along with the initial estimates for the
> implementation work (specified in days).
>
> Please review as soon as possible because we need to incorporate this in our
> release schedule this week.
>
> Thanks,
> Marcin
>
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.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 10, Issue 1
**************************************
