[kea-dev] select an IPv4 address on interface with multiple addresses

[Marcin Siodelski]

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:marcin at isc.org]
> > Envoyé : mardi 23 décembre 2014 12:51
> > À : Chaigneau, Nicolas; kea-dev at lists.isc.org
> > 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.
>