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: select an IPv4 address on interface with multiple
addresses (Chaigneau, Nicolas)
2. Re: Lease File Cleanup in Kea - Design Document
(Chaigneau, Nicolas)
3. Re: select an IPv4 address on interface with multiple
addresses (Marcin Siodelski)
4. Re: Lease File Cleanup in Kea - Design Document
(Marcin Siodelski)
5. Re: Lease File Cleanup in Kea - Design Document (Stephen Morris)
6. Re: Lease File Cleanup in Kea - Design Document
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Jan 2015 14:20:06 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] select an IPv4 address on interface with
multiple addresses
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194c9...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've tested the possibility to configure a specific listening address of an
interface.
It doesn't seem to do anything useful:
- I can't start two Kea servers listening on two different addresses of the
same interface
- I can't start one Kea server listening on two different addresses of the same
interface
- One Kea server will still answer to packets sent to any address of the
interface, even when configured for a single listen address
(this with Kea built with "direct_response_desired = false" so raw sockets are
not used)
I believe these points are addressed as part of ticket #3547 ? I see you've
been working on that one.
If you have something you want me to test early, I can do that. Just push the
commits on GitHub and tell me :)
Regards,
Nicolas.
> -----Message d'origine-----
> De : Marcin Siodelski [mailto:[email protected]]
> Envoy? : mardi 23 d?cembre 2014 12:51
> ? : Chaigneau, Nicolas; [email protected]
> Objet : Re: [kea-dev] Malformed packets returned by Kea
>
> 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, 26 Jan 2015 14:34:31 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194c9...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello Marcin,
A point which I forgot to address, regarding the "concurrent runs" issue:
"The kea-lfc implements locking using the PID file to prevent concurrent runs.
When the kea-lfc is started, it checks for the presence of the PID file. If the
file exists, it checks if the process with a PID from the PID file is running.
If the process is running, the application terminates. If the PID file doesn't
exist or the process with a given PID is not running, the kea-lfc creates a new
PID file with its own PID and continues to run."
Several kea servers may run on a single host, each having its own separate
configuration.
Consequently, kea-lfc must also be allowed to run concurrently (one instance of
kea-lfc matching each instance of kea).
To allow this, the PID file should be configurable. I think the logical place
would be in kea's configuration file.
Regards,
Nicolas.
> All,
>
> I have updated the Lease File Cleanup design with the comments from Stephen
> and Tomek (see ticket #3685). You may want to have a look and see if there is
> anything glaring. Minor comments like: spelling errors, some naming
> conventions may also be useful but they have little chance of being applied
> by the 0.9.1 release.
>
> The major change (which was actually applied in the LFC requirements
> document): http://kea.isc.org/wiki/LeaseFileCompressionRequirements is the
> removal of the following requirement:
>
> "b. The LFC should not remove the contents of the lease file which is not
> identified as a lease information or is an invalid lease information."
>
> Although, I initially thought it would be a useful capability, I now tend to
> think that it is not worth the effort for the following reasons:
> - We don't support comments in the lease files, and I don't think that
> supporting them really makes any sense, because lease file is not meant to be
> edited manually
> - If the server crashes when it is writing a lease into the lease file, and
> the lease information is incomplete, the server could rewrite the incomplete
> lease to the new file. But, how this incomplete entry would be fixed?
> Manually? By that time the client would probably return and get its lease
> back.
>
> However, the most important point is that implementation of this capability
> would require tracking the position of the unparsable data in the source
> lease file so as it will be rewritten in the same position (e.g. between
> lease X and Y) in the output file. At the same time, the updated LFC
> algorithm now loads all leases into memory, instead of reading and writing
> them one-by-one which makes it troublesome to match the position of the
> particular piece of unparsable information within the lease data structure,
> because current data structures do not support this capability.
>
> Please read the design document: http://kea.isc.org/wiki/LFCDesign and report
> issues on the mailing list.
>
> 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, 26 Jan 2015 16:02:58 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] select an IPv4 address on interface with
multiple addresses
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Nicolas,
I think we may have been unclear about your use cases. I apologize if
this is my misunderstanding.
See comments below.
Marcin
On 01/26/15 15:20, Chaigneau, Nicolas wrote:
>
> Hello,
>
>
> I've tested the possibility to configure a specific listening address
> of an interface.
>
> It doesn't seem to do anything useful:
> - I can't start two Kea servers listening on two different addresses
> of the same interface
That should work but I will double check to make sure.
> - I can't start one Kea server listening on two different addresses of
> the same interface
Initially when we talked about it I thought you were running multiple
instances of the DHCP server and each DHCP server would bind to a
different address. So, you used to use two instances of the server
because there was no other possibility with dhcpd and with Kea you would
like to run just one?
> - One Kea server will still answer to packets sent to any address of
> the interface, even when configured for a single listen address
>
The way Kea works (and worked in the past) is that for each address and
interface on which it should listen, it creates a socket, binds to a
specific address on this interface and captures both unicast and
broadcast traffic on this interface.
When we discussed the issues with unicast addresses you seemed to
indicate that the major pain was that the socket was bound to an
interface/device and received packets on this interface, even though
they were sent to a different destination address on that interfaces.
This has been corrected now. But, this was the case when raw socket was
in use (direct_response_desired = "true"). What I didn't realize realize
was that you're actually going to use the ip/udp sockets
(direct_response_desired = "false), not raw sockets.
> (this with Kea built with "direct_response_desired = false" so raw
> sockets are not used)
>
Again, Kea doesn't yet (until #3604) support switching between use of
raw sockets and ip/udp sockets. It always uses raw sockets. The trick
with a direct_response_desired is a "hack" which allows you to test the
use of ip/udp sockets.
Now that I understand a little more about your use cases it seems to me
that what you ask for is:
- an ability to open multiple sockets on a single interface (assuming
they are not raw sockets because for raw sockets you have to bind socket
to the device), within a single DHCP server instance - this is not
supported at present and implementing this would require a new ticket.
It is doable, but #3604 must go in first because it can only be done for
the ip/udp socket case. For raw socket it is way more complicated (not
impossible, though).
- a configuration knob which to select between the use raw sockets and
udp sockets (for unicast traffic) - covered in #3604, with an additional
ability to disable the broadcast traffic on the interface on which
ip/udp socekts are in use.
Please confirm.
The question I have is this. Since you want to use the ip/udp sockets
(only relayed traffic, I suppose), you probably desire to use IP tables.
With a raw socket you couldn't use IP tables because packets will bypass
the iptables. So one choice you have, when #3604 is done, is to setup ip
tables to filter out broadcast packets, in which case Kea doesn't have
to do it. Would that work?
>
> I believe these points are addressed as part of ticket #3547 ? I see
> you've been working on that one.
>
> If you have something you want me to test early, I can do that. Just
> push the commits on GitHub and tell me :)
>
>
> Regards,
> Nicolas.
>
>
> > -----Message d'origine-----
> > De : Marcin Siodelski [mailto:[email protected]]
> > Envoy? : mardi 23 d?cembre 2014 12:51
> > ? : Chaigneau, Nicolas; [email protected]
> > Objet : Re: [kea-dev] Malformed packets returned by Kea
> >
> > 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: 4
Date: Mon, 26 Jan 2015 16:05:49 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Nicolas,
Ok, this is actually a good point. The pid file location or at least its
name should be configurable in runtime.
So, with regards to the previous email you sent today. Is your use case
to run multiple instances of the DHCP server or one instance listening
on multiple interfaces/addresses. Or both?
Marcin
On 01/26/15 15:34, Chaigneau, Nicolas wrote:
>
> Hello Marcin,
>
>
> A point which I forgot to address, regarding the "concurrent runs" issue:
>
> "The kea-lfc implements locking using the PID file to prevent
> concurrent runs. When the kea-lfc is started, it checks for the
> presence of the PID file. If the file exists, it checks if the process
> with a PID from the PID file is running. If the process is running,
> the application terminates. If the PID file doesn't exist or the
> process with a given PID is not running, the kea-lfc creates a new PID
> file with its own PID and continues to run."
>
>
> Several kea servers may run on a single host, each having its own
> separate configuration.
> Consequently, kea-lfc must also be allowed to run concurrently (one
> instance of kea-lfc matching each instance of kea).
> To allow this, the PID file should be configurable. I think the
> logical place would be in kea's configuration file.
>
>
>
> Regards,
> Nicolas.
>
>
> > All,
> >
> > I have updated the Lease File Cleanup design with the comments from
> Stephen and Tomek (see ticket #3685). You may want to have a look and
> see if there is anything glaring. Minor comments like: spelling
> errors, some naming conventions may also be useful but they have
> little chance of being applied by the 0.9.1 release.
> >
> > The major change (which was actually applied in the LFC requirements
> > document): http://kea.isc.org/wiki/LeaseFileCompressionRequirements
> is the removal of the following requirement:
> >
> > "b. The LFC should not remove the contents of the lease file which
> is not identified as a lease information or is an invalid lease
> information."
> >
> > Although, I initially thought it would be a useful capability, I now
> tend to think that it is not worth the effort for the following reasons:
> > - We don't support comments in the lease files, and I don't think
> that supporting them really makes any sense, because lease file is not
> meant to be edited manually
> > - If the server crashes when it is writing a lease into the lease
> file, and the lease information is incomplete, the server could
> rewrite the incomplete lease to the new file. But, how this incomplete
> entry would be fixed? Manually? By that time the client would probably
> return and get its lease back.
> >
> > However, the most important point is that implementation of this
> capability would require tracking the position of the unparsable data
> in the source lease file so as it will be rewritten in the same
> position (e.g. between lease X and Y) in the output file. At the same
> time, the updated LFC algorithm now loads all leases into memory,
> instead of reading and writing them one-by-one which makes it
> troublesome to match the position of the particular piece of
> unparsable information within the lease data structure, because
> current data structures do not support this capability.
> >
> > Please read the design document: http://kea.isc.org/wiki/LFCDesign
> and report issues on the mailing list.
> >
> > 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: 5
Date: Mon, 26 Jan 2015 15:25:51 +0000
From: Stephen Morris <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 26/01/15 15:05, Marcin Siodelski wrote:
> Nicolas,
>
> Ok, this is actually a good point. The pid file location or at least its
> name should be configurable in runtime.
The files for different servers should be different, but I don't think
we need another configuration item.
When LFC runs, it outputs/uses intermediate files, the names of which
are formed by appending a suffix to the name of the configured lease
file. We should do the same for the pid file - append something like
".pid" to the end of the lease file name.
Stephen
------------------------------
Message: 6
Date: Mon, 26 Jan 2015 16:09:33 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lease File Cleanup in Kea - Design Document
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194c9...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
> Nicolas,
>
>
> So, with regards to the previous email you sent today. Is your use case to
> run multiple instances of the DHCP server or one instance listening on
> multiple interfaces/addresses. Or both?
Ideally: both, with no raw sockets.
Here are some explanation, then I'll look into your other mail and answer more
in detail if some points are still unclear.
I have multiple DHCP relays, which send messages to my DHCP servers (which are
all on the same physical host), using distinct destination IP addresses of the
same interface.
My server has one interface, with many IP addresses.
In order to take advantage of the 12 CPU available, I need to be able to launch
several processes, each one listening on a (distinct) subset of the interface
addresses.
With dhcpd, I'm forced to start one server for each listening address, *but* I
don't want that many.
I'd like to have one Kea server handle several listening addresses, and one
physical server to host several Kea servers.
To clarify the raw sockets issue...
I don't want raw sockets at all, because:
- first I don't need them: in my setup all requests come through a relay. I
don't have to handle broadcast messages or direct responses.
- second, I want to be able to filter out packets (through iptables) before
they reach the DHCP server. Which is not feasible with raw sockets.
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.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 10, Issue 6
**************************************
