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: Relay Agent Option (Tomek Mrugalski)
2. Lease File Compression Requirements (Marcin Siodelski)
3. Re: Lease File Compression Requirements (Stephen Morris)
4. Re: Lease File Compression Requirements (Alexis)
5. Re: Lease File Compression Requirements (Marcin Siodelski)
6. Re: Lease File Compression Requirements (wlodek)
7. Re: Lease File Compression Requirements (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Dec 2014 13:02:05 +0100
From: Tomek Mrugalski <[email protected]>
To: anuj chauhan <[email protected]>, [email protected]
Subject: Re: [kea-dev] Relay Agent Option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 16.12.2014 12:35, anuj chauhan wrote:
> Can someone please help me to find out which class of kea-dhcp code is
> responsible for reading a dhcpdiscover packet.and
> and selecting a subnet based on relay agent ip address.
Discover packet (and any other DHCPv4 packet) is being represented by
isc::dhcp::Pkt4 (in src/lib/dhcp/pkt4.cc|h). The subnet selection
process is conducted in isc::dhcp::Dhcpv4Srv::selectSubnet() (in
src/bin/dhcp4/dhcp4_srv.cc|h).
> Can I use Relay Agent suboption*/remote id/* to assign a specific ip
> address.If yes How do i get to that part of Code in dhcpserver.
No, you currently can't. We are currently working on adding host
reservation mechanism that is planned for our next release - 0.9.1. It
will allow reserving specific IPv4/ IPv6 address and IPv6 prefixes for a
given host. The plan for 0.9.1 is to allow reservations by MAC address
and client-id. We currently do not have plans to implement reservation
by remote-id.
Having said that, this is our initial implementation of the host
reservation mechanism. We plan to extend it over time, but we don't have
specific plans defined yet. Feedback such a yours is very useful for us.
Features that are requested by users are more likely to be considered
for our roadmap. And, as usual, patches are more than welcome. But
before you consider writing new code, please read our Contributor's
Guide (http://kea.isc.org -> Developer's Guide -> Contributor's Guide).
If you are interested in this code, it is currently available on
trac3564. You may find its description here:
http://kea.isc.org/ticket/3564. We're hoping to have this code merged to
master by end of this week.
Hope that helps,
Tomek
------------------------------
Message: 2
Date: Tue, 16 Dec 2014 13:02:28 +0100
From: Marcin Siodelski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
Recently we had a discussion on the mailing list about the lease file
clean-up in Kea, initiated by Nicolas Chaigneau.
Please see this thread and follow-ups here:
https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
It is an important functionality required to keep the size of the lease
file at the reasonable level, by periodically removing the redundant
information from it.
As a first step towards the implementation of this feature in Kea, I
created a page with requirements:
http://kea.isc.org/wiki/LeaseFileCompressionRequirements
All input to this document is welcome.
I am planning on creating an accompanying design document using the
requirements presented here.
Again, please share your thoughts.
Thanks,
Marcin
------------------------------
Message: 3
Date: Tue, 16 Dec 2014 12:22:07 +0000
From: Stephen Morris <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 16/12/14 12:02, Marcin Siodelski wrote:
> As a first step towards the implementation of this feature in Kea,
> I created a page with requirements:
>
> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>
> All input to this document is welcome.
>
> I am planning on creating an accompanying design document using the
> requirements presented here.
>
> Again, please share your thoughts.
(Commenting on version 3 of the requirements.)
The requirements look OK, but the only one I question is 2.d "The LFC
must not spread the lease information in multiple lease files. The only
exception is the period before the start and end of LFC." This
requirement seems to introduce extra complexity for little gain.
The emails in the thread:
https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
have suggested a method of LFC compression where the server renames
the current lease file and opens a new one; compression then takes
place asynchronously on the old file. This would mean that for
virtually all the time the server is operating there are two files -
the current one and the compressed one. (I'm assuming that when LFC
kicks in, it would combine any old files with the one it is processing.)
As the first email in the thread suggests, combining the compressed
lease file with the current one means interrupting processing for a
short while the server appends the latter to the former. I suggest
that most operators are not too concerned about the contents of the
file, so whether the lease information is in one file or split between
two is of no concern to them. If they do require a single file
containing snapshot of all the leases, it is simple to concatenate the
two files.
Stephen
------------------------------
Message: 4
Date: Tue, 16 Dec 2014 09:44:47 -0300
From: Alexis <[email protected]>
To: Stephen Morris <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
will this ensure a way to keep the file/s synced (rsync maybe) to other
'standby' servers and able to assume in case of a switchover?
nowadays it's near requirement to have redundancy (active/active if possible)
just a note.
actually I'm deploying 2 servers right now, both active using a database
backend to serve around 60k leases for telephony devices and having 2 or 3
servers was a requirement from my customer
Enviado desde mi iPhone
> El dic 16, 2014, a las 9:22, Stephen Morris <[email protected]> escribi?:
>
>> On 16/12/14 12:02, Marcin Siodelski wrote:
>>
>> As a first step towards the implementation of this feature in Kea,
>> I created a page with requirements:
>>
>> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>>
>> All input to this document is welcome.
>>
>> I am planning on creating an accompanying design document using the
>> requirements presented here.
>>
>> Again, please share your thoughts.
>
> (Commenting on version 3 of the requirements.)
>
> The requirements look OK, but the only one I question is 2.d "The LFC
> must not spread the lease information in multiple lease files. The only
> exception is the period before the start and end of LFC." This
> requirement seems to introduce extra complexity for little gain.
>
> The emails in the thread:
>
> https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
>
> have suggested a method of LFC compression where the server renames
> the current lease file and opens a new one; compression then takes
> place asynchronously on the old file. This would mean that for
> virtually all the time the server is operating there are two files -
> the current one and the compressed one. (I'm assuming that when LFC
> kicks in, it would combine any old files with the one it is processing.)
>
> As the first email in the thread suggests, combining the compressed
> lease file with the current one means interrupting processing for a
> short while the server appends the latter to the former. I suggest
> that most operators are not too concerned about the contents of the
> file, so whether the lease information is in one file or split between
> two is of no concern to them. If they do require a single file
> containing snapshot of all the leases, it is simple to concatenate the
> two files.
>
> Stephen
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 5
Date: Tue, 16 Dec 2014 14:32:01 +0100
From: Marcin Siodelski <[email protected]>
To: Stephen Morris <[email protected]>, [email protected]
Subject: Re: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 16/12/14 13:22, Stephen Morris wrote:
> On 16/12/14 12:02, Marcin Siodelski wrote:
>
>> As a first step towards the implementation of this feature in Kea,
>> I created a page with requirements:
>>
>> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>>
>> All input to this document is welcome.
>>
>> I am planning on creating an accompanying design document using the
>> requirements presented here.
>>
>> Again, please share your thoughts.
>
> (Commenting on version 3 of the requirements.)
>
> The requirements look OK, but the only one I question is 2.d "The LFC
> must not spread the lease information in multiple lease files. The only
> exception is the period before the start and end of LFC." This
> requirement seems to introduce extra complexity for little gain.
>
> The emails in the thread:
>
> https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
>
> have suggested a method of LFC compression where the server renames
> the current lease file and opens a new one; compression then takes
> place asynchronously on the old file. This would mean that for
> virtually all the time the server is operating there are two files -
> the current one and the compressed one. (I'm assuming that when LFC
> kicks in, it would combine any old files with the one it is processing.)
>
> As the first email in the thread suggests, combining the compressed
> lease file with the current one means interrupting processing for a
> short while the server appends the latter to the former. I suggest
> that most operators are not too concerned about the contents of the
> file, so whether the lease information is in one file or split between
> two is of no concern to them. If they do require a single file
> containing snapshot of all the leases, it is simple to concatenate the
> two files.
>
In the aforementioned thread we have discussed two options: with and
without combining the currently used file with the compressed file
during LFC. See:
https://lists.isc.org/pipermail/kea-dev/2014-November/000190.html
In case of the option 1 the following sequence is followed:
- LFC1 kicks in
- Server ceases handling packets
- Lease file foo.leases is renamed to foo.leases.old
- Lease file foo.leases is recreated and is empty
- Server continues handling packets
- LFC compresses foo.leases.old (background)
- LFC1 ends
- Server continues using foo.leases
- LFC2 kicks in
- Server ceases handling packets
- Lease file foo.leI don't think that the other approach has a lot of
overheadases is appended to foo.leases.old
- Lease foo.leases is recreated and is empty
- Server continues handline packets
- LFC compresses foo.leases.old (background)
- LFC2 ends
- Server continues using foo.leases
In this case, yes, there are at least two files in use all the time and
the requirement doesn't make sense.
There is option 2:
- LFC1 kicks in
- Server ceases handling packets
- Lease file foo.leases.new is created and is empty
- Server uses foo.leases.new for recording current lease updates
- Server continues handling packets
- LFC compresses foo.leases (background)
- Server ceases handling packets
- LFC appends the contents of foo.leases.new to foo.leases
- Server uses foo.leases for recording current lease updates
- Server continues handling packets
- LFC1 ends
- etc.
In case of option 2 you'd have one lease file for most of the time and
the only situation when you'd have two is the LFC period. Here is where
the requirement comes from.
The option 2 has a downside that you'd need to perform additional IO
operation to append the contents of the foo.leases.new to foo.leases. It
also needs time to switch over from using the foo.leases to
foo.leases.new and back.
So, option 2 is a bit slower. Actually, the performance penalty depends
on the rate at which clients acquire/renew leases relative to the time
of LFC.
I thought it would be better from the administrative point of view to
have one lease file, instead of two. But, if we feel it is not
compelling reason given the performance penalty I am ok to go with option 1.
Marcin
------------------------------
Message: 6
Date: Tue, 16 Dec 2014 14:53:27 +0100
From: wlodek <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hello,
Little idea: I think another trigger could be useful. Manual trigger for
administrators - start LFC on demand.
W?odek
On 12/16/2014 01:02 PM, Marcin Siodelski wrote:
> Hi,
>
> Recently we had a discussion on the mailing list about the lease file
> clean-up in Kea, initiated by Nicolas Chaigneau.
>
> Please see this thread and follow-ups here:
> https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
>
> It is an important functionality required to keep the size of the lease
> file at the reasonable level, by periodically removing the redundant
> information from it.
>
> As a first step towards the implementation of this feature in Kea, I
> created a page with requirements:
>
> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>
> All input to this document is welcome.
>
> I am planning on creating an accompanying design document using the
> requirements presented here.
>
> Again, please share your thoughts.
>
> Thanks,
> Marcin
>
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 7
Date: Tue, 16 Dec 2014 15:03:37 +0100
From: Marcin Siodelski <[email protected]>
To: Alexis <[email protected]>, Stephen Morris <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lease File Compression Requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Being able to sync the lease files between the servers it is an
important requirement for the deployment using DHCP servers. But I am
afraid that it is a whole different feature. Note that there will be
more redundancy considerations once we come round to design and
implementation of the failover. But, this is currently out of scope.
One option for now would probably be to run rsync as a cron job to
populate lease files from one place to another.
Marcin
On 12/16/14 13:44, Alexis wrote:
> will this ensure a way to keep the file/s synced (rsync maybe) to other
> 'standby' servers and able to assume in case of a switchover?
>
> nowadays it's near requirement to have redundancy (active/active if possible)
>
> just a note.
>
> actually I'm deploying 2 servers right now, both active using a database
> backend to serve around 60k leases for telephony devices and having 2 or 3
> servers was a requirement from my customer
>
> Enviado desde mi iPhone
>
>> El dic 16, 2014, a las 9:22, Stephen Morris <[email protected]> escribi?:
>>
>>> On 16/12/14 12:02, Marcin Siodelski wrote:
>>>
>>> As a first step towards the implementation of this feature in Kea,
>>> I created a page with requirements:
>>>
>>> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>>>
>>> All input to this document is welcome.
>>>
>>> I am planning on creating an accompanying design document using the
>>> requirements presented here.
>>>
>>> Again, please share your thoughts.
>>
>> (Commenting on version 3 of the requirements.)
>>
>> The requirements look OK, but the only one I question is 2.d "The LFC
>> must not spread the lease information in multiple lease files. The only
>> exception is the period before the start and end of LFC." This
>> requirement seems to introduce extra complexity for little gain.
>>
>> The emails in the thread:
>>
>> https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
>>
>> have suggested a method of LFC compression where the server renames
>> the current lease file and opens a new one; compression then takes
>> place asynchronously on the old file. This would mean that for
>> virtually all the time the server is operating there are two files -
>> the current one and the compressed one. (I'm assuming that when LFC
>> kicks in, it would combine any old files with the one it is processing.)
>>
>> As the first email in the thread suggests, combining the compressed
>> lease file with the current one means interrupting processing for a
>> short while the server appends the latter to the former. I suggest
>> that most operators are not too concerned about the contents of the
>> file, so whether the lease information is in one file or split between
>> two is of no concern to them. If they do require a single file
>> containing snapshot of all the leases, it is simple to concatenate the
>> two files.
>>
>> Stephen
>>
>> _______________________________________________
>> kea-dev mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-dev
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 9, Issue 4
*************************************
