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: I'd appreciate some feedback on trac ticket 3963 :)
(Marcin Siodelski)
2. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Angelo Failla)
3. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Aug 2015 21:07:41 +0200
From: Marcin Siodelski <[email protected]>
To: Angelo Failla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 04.08.2015 21:43, Angelo Failla wrote:
> On August 4, 2015 at 6:30:09 PM, Marcin Siodelski ([email protected]
> <mailto:[email protected]>) wrote:
> >
> >
> > On 04.08.2015 17:35, Angelo Failla wrote:
> > > On August 4, 2015 at 4:34:30 PM, Marcin Siodelski ([email protected]
> > > <mailto:[email protected]>) wrote:
> > >>
> > >> > one nice thing to also get rid of, when enabling the stateless
> switch,
> > >> > is to
> > >> > avoid this horrible hack to allow KEA to start :)
> > >> >
> > >> > 'subnet4' => [
> > >> > {
> > >> > 'subnet' => '0.0.0.0/0',
> > >> > 'pools' => [{ 'pool' => '0.0.0.0-255.255.255.255' }]
> > >> > },
> > >> > ],
> > >> >
> > >>
> > >> As a matter of curiosity. If you're having this hack already
> could you
> > >> possibly implement the lease4_select hook to set the yiaddr to
> non-zero
> > >> value in the DHCPOFFER, which would case processDiscover to not
> drop the
> > >> packet?
> > >>
> > >
> > > Yeah, I will try that and report back.
> >
> >
> > Actually, wouldn't it suffice to just restrict the pool to
> > 0.0.0.1-255.255.255.255C?
> >
> > That way none of the clients would ever be assigned a zero address and
> > the packet wouldn't be dropped.
>
> So I tried that, and compiled my hook lib w/o the change
> in https://github.com/isc-projects/kea/pull/11
> and it doesn?t solve the problem, I see that only my pkt4_receive
> callout gets called, then I see
>
> 2015-08-04 12:34:59.869 ERROR [kea-dhcp4.bad-packets/966953]
> DHCP4_PACKET_NAK_0001
> [hwtype=1 00:02:c9:de:70:4e], cid=[no info], tid=0x2eed: failed to
> select a subnet for incoming packet,
> src 10.35.139.81, type DHCPDISCOVER
>
> and that?s it. no pkt4_send is called.
>
> config has this:
>
> "subnet4": [
> {
> "subnet": "0.0.0.1/0",
> "pools": [
> {
> "pool": "0.0.0.1-255.255.255.255"
> }
> ]
> }
> ]
>
> Anyway, it?s not a big deal, we got a version that is going to prod with
> my github change above for the time
> being.
>
> let me know how your meeting goes in relation to the proposed change.
>
Angelo,
We have accepted this work for 1.0 assuming that you will write the code
for it. I do think it is quite a straight forward change. One thing I
haven't pointed out in the ticket, and which may be worth some
clarification, is that we would like to have a 'runtime' configuration
parameter, rather than the compilation time parameter to enable
stateless mode.
One question I had is this. Do you require sending different sets of
options depending on the location of the client in the network? So for
example: for the clients from which the packet is received on this
interface you send these options, and for the clients connected to
another interface other options? Or accordingly for different relays
when dealing with the relayed traffic?
Marcin
Marcin
------------------------------
Message: 2
Date: Wed, 5 Aug 2015 20:08:31 +0000
From: Angelo Failla <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?
On August 5, 2015 at 8:07:53 PM, Marcin Siodelski
([email protected](mailto:[email protected])) wrote:
> Angelo,
>
> We have accepted this work for 1.0 assuming that you will write the code
> for it.
\o/
Yeah, I will work on it, how does your review process work? I red the dev
guide, I don?t have access to your internal git repo, I guess you are ok with a
PR
on github?
> I do think it is quite a straight forward change. One thing I
> haven't pointed out in the ticket, and which may be worth some
> clarification, is that we would like to have a 'runtime' configuration
> parameter, rather than the compilation time parameter to enable
> stateless mode.
yeah I?d like some clarification on this part, do you have an example
in?the code of a??runtime??configuration parameter?
I guess I can look it out myself but asking here is quicker :)
For ?runtime? configuration param I guess you mean configuration that doesn't
require a complete restart of the daemons right?
Did you already create a TRAC ticket for this proposed change?
I can?t find it.
> One question I had is this. Do you require sending different sets of
> options depending on the location of the client in the network? So for
> example: for the clients from which the packet is received on this
> interface you send these options, and for the clients connected to
> another interface other options? Or accordingly for different relays
> when dealing with the relayed traffic?
What do you mean by different set of options? Do you mean different DHCP
sent to the clients? Or you are referring to KEA config options?
But no, we really just need a single set of options: we don?t care on which
interface a client is hitting us on.
Maybe explaining our setup can help responding to your question:
- we only serve relayed traffic
- all rack switches in our DCs runs a DHCP relayer
- each relayer is configured to forward traffic to a global BGP anycast VIP
- KEA servers across the fleet receive the traffic on that VIP
--
Angelo Failla - Cluster Infrastructure Dublin
[email protected]
------------------------------
Message: 3
Date: Thu, 6 Aug 2015 09:59:19 +0200
From: Marcin Siodelski <[email protected]>
To: Angelo Failla <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05.08.2015 22:08, Angelo Failla wrote:
>
> On August 5, 2015 at 8:07:53 PM, Marcin Siodelski
> ([email protected](mailto:[email protected])) wrote:
>
>> Angelo,
>>
>> We have accepted this work for 1.0 assuming that you will write the code
>> for it.
>
> \o/
> Yeah, I will work on it, how does your review process work? I red the dev
> guide, I don?t have access to your internal git repo, I guess you are ok with
> a PR
> on github?
>
We maintain the clone of the internal repository on github. In fact, it
is not so much internal, but for external people it is read only.
Nevertheless, we want people to use the github repo for contributions:
http://github.com/isc-projects/kea
You should fork this repo (if you haven't done that already) and issue
pull request when you're ready for a review of your code.
The ticket is here: http://kea.isc.org/ticket/3964
Please assign this ticket to yourself (assuming you have a account in
our trac system). If you don't, I'll just assign it to a generic person
called "contributor". When it is assigned to you or contributor it is an
information for others to not take this ticket because someone else is
working on it.
Did you read this in the developer's guide:
http://git.kea.isc.org/~tester/kea/doxygen/d7/df4/contributorGuide.html ?
It is important to make sure that you follow the coding style and make
sure that proper unit tests are implemented. We follow the test driven
development, so the test should be created first, then the actual code.
To enable compilation of tests (google tests) you need to specify
--with-gtest as a configuration parameter when building Kea.
When you fork the repo please create the branch trac3964. It will be
easier for me to find this code in your fork, as this is the naming
convention for branches dedicated for specific tickets.
>> I do think it is quite a straight forward change. One thing I
>> haven't pointed out in the ticket, and which may be worth some
>> clarification, is that we would like to have a 'runtime' configuration
>> parameter, rather than the compilation time parameter to enable
>> stateless mode.
>
> yeah I?d like some clarification on this part, do you have an example
> in the code of a ?runtime? configuration parameter?
> I guess I can look it out myself but asking here is quicker :)
> For ?runtime? configuration param I guess you mean configuration that doesn't
> require a complete restart of the daemons right?
>
By 'runtime' parameter I mean the parameter that is specified in the Kea
configuration (json) file.
I think you could take the 'echo-client-id' as an example. It is a
boolean flag in the global scope of the configuration. Your parameter
will be defined in the similar way. Please make sure you include a
proper declaration for your new parameter in the
src/bin/dhcp4/dhcp4.spec file.
It may be a good idea to grep for 'echo-client-id' in the src/bin/dhcp4
and you will find out how to implement the logic required for your new
parameter to be interpreted by the server. You'll also find how unit
tests for it can be implemented.
> Did you already create a TRAC ticket for this proposed change?
> I can?t find it.
>
See above.
>> One question I had is this. Do you require sending different sets of
>> options depending on the location of the client in the network? So for
>> example: for the clients from which the packet is received on this
>> interface you send these options, and for the clients connected to
>> another interface other options? Or accordingly for different relays
>> when dealing with the relayed traffic?
>
> What do you mean by different set of options? Do you mean different DHCP
> sent to the clients? Or you are referring to KEA config options?
> But no, we really just need a single set of options: we don?t care on which
> interface a client is hitting us on.
>
Oh, I meant different DHCP options sent by the server to the client. So
you don't really need to do any subnet specific configurations.
What will be needed on the server side is to make sure that in the
stateless mode:
The server shouldn't require that the subnet is selected, which is
currently required by many functions like appendRequestedOptions.
They currently use the subnet->getCfgOption() to retrieve subnet
specific options, but in your case they'd need to use
CfgMgr::instance().getCurrentCfg()->getCfgOption() which holds top level
options (because we don't use subnets in statless mode). Whether it uses
top level options or subnet options should depend on whether you're in
stateless or stateful mode.
Perhaps you could just reuse the solution from the
"appendRequestedOptions" implemented in the DHCPv6 server. Note that it
also does the stateless configuration when Information-request is sent.
> Maybe explaining our setup can help responding to your question:
>
> - we only serve relayed traffic
> - all rack switches in our DCs runs a DHCP relayer
> - each relayer is configured to forward traffic to a global BGP anycast VIP
> - KEA servers across the fleet receive the traffic on that VIP
>
Hope that helps a bit,
Marcin
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 17, Issue 6
**************************************
