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: installation report on debian wheezy (Marcin Siodelski)
2. Re: Re-designing the config parsers (Francis Dupont)
3. Re: Re-designing the config parsers (Tomek Mrugalski)
4. Re: Re-designing the config parsers (Francis Dupont)
5. Re: Use cases and questions regarding lease allocation
(Marcin Siodelski)
6. Re: Use cases and questions regarding lease allocation
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Sep 2014 16:19:52 +0200
From: Marcin Siodelski <[email protected]>
To: Michael Richardson <[email protected]>, [email protected]
Subject: Re: installation report on debian wheezy
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Michael,
Not that long ago we realized that the default kea.conf file is broken
and should have been updated after renaming configuration parameter
"pool" to "pools" and changing its type from the string to a *list of maps*.
Fix for this is to be covered in this ticket:
http://kea.isc.org/ticket/3538 (which is BTW in the review queue).
We also know that the loggers configuration needs an update in the guide
and in the kea.conf. And yes, it is completely wrong. See this ticket:
http://kea.isc.org/ticket/3536
If I understand correctly your last statement you feel that specifying
an option is a pain? I agree. Historically, it was because the old
BIND10 infrastructure didn't handle the default values of parameters
well. As a result you need to specify all parameters for each option.
We're also planning to address it in the next Kea release:
http://kea.isc.org/ticket/3467
Thanks for your efforts!
Marcin
On 10/09/14 03:43, Michael Richardson wrote:
> 4) despite repeated attempts, I can't make it like my config:
>
> # DHCPv4 configuration starts here.
> "Dhcp4":
> {
> # Add names of interfaces to listen on.
> "interfaces": [ "eth0" ],
>
> # Use Memfile lease database backend to store leases in a CSV file.
> "lease-database": {
> "type": "memfile"
> },
>
> # Global (inherited by all subnets) lease lifetime is mandatory parameter.
> "valid-lifetime": 4000,
>
> # Below an example of the simple subnet declaration. Uncomment to
> # enable it.
> "subnet4": [
> "subnet": "172.30.55.0/24", <--- seems to be line 25.
> "pools": [
> { "pool": "172.30.55.192/26" }
> ]
> ]
> },
>
> halibut-[~/kea] mcr 10106 %sudo keactrl start
> INFO/keactrl: Starting kea-dhcp4 -c /sandel/etc/kea/kea.conf
> INFO/keactrl: Starting kea-dhcp6 -c /sandel/etc/kea/kea.conf
> 2014-09-09 20:16:58.557 ERROR [kea-dhcp4.dhcp4/10390] DHCP4_INIT_FAIL failed
> to initialize Kea server: configuration error using file
> '/sandel/etc/kea/kea.conf': ':' read, one of ",]" expected in
> /sandel/etc/kea/kea.conf:25:17
> INFO/keactrl: Starting kea-dhcp-ddns -c /sandel/etc/kea/kea.conf
>
>
> 5) okay, I played some more, and with:
>
> "Dhcp4":
> {
> # Add names of interfaces to listen on.
> "interfaces": [ "eth0" ],
>
> # Use Memfile lease database backend to store leases in a CSV file.
> "lease-database": {
> "type": "memfile"
> },
>
> # Global (inherited by all subnets) lease lifetime is mandatory parameter.
> "valid-lifetime": 4000,
>
> # Below an example of the simple subnet declaration. Uncomment to
> # enable it.
> "subnet4": {
> "subnet": "172.30.55.0/24",
> "pools": [
> { "pool": "172.30.55.192/26" }
> ]
> }
> },
>
>
> (that is, subnet4, takes a directionary, not an array, I get:
>
> halibut-[~/kea] mcr 10113 %sudo keactrl start
> INFO/keactrl: Starting kea-dhcp4 -c /sandel/etc/kea/kea.conf
> INFO/keactrl: Starting kea-dhcp6 -c /sandel/etc/kea/kea.conf
> 2014-09-09 20:19:37.726 INFO [kea-dhcp4.dhcpsrv/10541]
> DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
> 2014-09-09 20:19:37.741 INFO [kea-dhcp4.dhcpsrv/10541] DHCPSRV_MEMFILE_DB
> opening memory file lease database: type=memfile universe=4
> 2014-09-09 20:19:37.749 INFO [kea-dhcp4.dhcpsrv/10541]
> DHCPSRV_MEMFILE_LEASES_RELOAD4 reloading leases from
> /sandel/var/kea/kea-leases4.csv
> 2014-09-09 20:19:37.760 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_PARSER_FAIL
> failed to create or run parser for configuration element subnet4: listValue()
> called on non-list Element
> 2014-09-09 20:19:37.763 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_CONFIG_LOAD_FAIL
> configuration error using file: /sandel/etc/kea/kea.conf, reason: listValue()
> called on non-list Element
> 2014-09-09 20:19:37.786 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_INIT_FAIL failed
> to initialize Kea server: configuration error using file
> '/sandel/etc/kea/kea.conf': listValue() called on non-list Element
> INFO/keactrl: Starting kea-dhcp-ddns -c /sandel/etc/kea/kea.conf
>
> which sort of seems to be an improvement, because it's no longer a parser
> error, but rather an semantic error, but it seemto suggest that the [] was
> right, but something about it was really wrong.
>
> AHA, the installed example CONFIG is CORRECT, but the documentation is
> totally borked. [] around :-items would be invalid JSON anyway.
>
> AHA 2... trailing , on dictionaries is not accepted.
> I'm pretty sure that Javascript deals with it just fine, btw.
>
> Finally, got it working. WII liked it, phones liked it.
> WTF... I gotta write the options out like that... wow... nobody gonna live
> with that long.
>
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 2
Date: Thu, 11 Sep 2014 16:01:39 +0000
From: Francis Dupont <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: Kea Dev List <[email protected]>
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Marcin Siodelski writes:
> I should also explain that we discussed with Tomek a use of Bison
> framework (http://www.gnu.org/software/bison/) in Kea.
=> I heavily used bison (and other LALR(1) parsers) in the past...
BTW if you want to provide a parser style config, IMHO the best
available is JunOS from Juniper (far better than the Cisco config).
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 11 Sep 2014 18:04:31 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 11.09.2014 18:01, Francis Dupont wrote:
> Marcin Siodelski writes:
>> I should also explain that we discussed with Tomek a use of Bison
>> framework (http://www.gnu.org/software/bison/) in Kea.
>
> => I heavily used bison (and other LALR(1) parsers) in the past...
> BTW if you want to provide a parser style config, IMHO the best
> available is JunOS from Juniper (far better than the Cisco config).
No, we don't want to change the format. It will stay as it is.
The plan is to refactor/redo the code that parses that input.
The input will stay as it is now: JSON syntax.
Tomek
------------------------------
Message: 4
Date: Thu, 11 Sep 2014 16:05:36 +0000
From: Francis Dupont <[email protected]>
To: Daniil Baturin <[email protected]>
Cc: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Daniil Baturin writes:
> What is wrong with Bison dependency? It's available from
> repositories/ports/etc.
> on any UNIX-like system in existence and can be installed even on
> platforms that do not exist anymore. :)
=> there are two different things with Bison:
- the grammar compiler into tables.
- the automaton using the tables.
The second is not very bound to Bison, I know some examples using
a language very different from C. In fact only the error report is
not straightforward...
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 5
Date: Thu, 11 Sep 2014 18:34:57 +0200
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Use cases and questions regarding lease allocation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Nicolas,
I think I may need to play with this some more, but so far I was not
able to reproduce issues that you described in use cases 1) to 3).
I made this simple test:
- I setup two machines: one with the Kea server, another one with the
dhclient.
- I configured one subnet on the Kea server and associated with the
interface to which the client was directly connected.
- I started the dhclient and it obtained the lease with the address from
the pool 192.0.2.100 - 192.0.2.200. The address it got was the first one
from the pool: 192.0.2.100.
- I stopped dhclient and Kea.
- I removed the Kea lease file to simulate the case that the server
doesn't know the client.
- I modified the dhclient lease file and altered the address from
192.0.2.100 to 192.0.2.110 so as the dhclient requests the 192.0.2.110
address specifically, not the 192.0.2.100 which would be allocated for
the client even if not requested
- I started up Kea
- I ran dhclient using the modified lease file.
- I checked with the wireshark that the dhclient sent Discover
requesting the 192.0.2.110 in the requested IP address option. No other
fields were set (e.g. ciaddr was set to all zeros)
- The server responded with an Offer with yiaddr = 192.0.2.110 as
requested by the client.
- The client sent the Request with 192.0.2.110 and got Ack with this
yiaddr from the server.
The support for Requested IP Address option was added not so long ago. I
wonder if you're using a recent version of Kea? Is this Kea 0.9-beta,
Kea 0.9 relase or any other?
Also, are you using a Memfile or some other lease database backend?
Could you send a traffic capture?
As for the use case 4). I was able to reproduce it and I agree that the
issue exists. I'll submit the ticket for it. Thanks!
Regarding use case 5).
When the client C1 sends Discover and is offered an address it is going
to be a rare case that the client C2 requests the same address before
the client C1 requests it. It could happen if the client C2 was using
this address before, and is renewing it and the server doesn't have a
record of this client.
If we wanted to address this use case we'd need to keep the collection
of offered leases which brings additional complexity: when to release
the offered address if client didn't get back for it, marking the
address offered has performance penalties etc. So, in my opinion it is
not worth an effort given that the case you're describing should be
relatively rare.
Marcin
On 09/09/14 17:03, Chaigneau, Nicolas wrote:
> Hello,
>
>
>
>
>
> I?ve done some more testing, and have questions related to some use
> cases (which I compared to how dhcpd behaves).
>
>
>
> Note that the point of this mail is not to report defects ; I?m merely
> trying to understand what may be design choices.
>
> (Nothing here is, strictly speaking, against the RFC, but some ?should?
> and ?should not? are not enforced.)
>
>
>
> Anyway, here goes.
>
>
>
>
>
>
>
> 1) Use case 1:
>
> - Client C1 sends a Discover, is offered lease L1.
>
> - Client C1 sends a Request, with Requested IP Address = L1.
>
> - Client C1 gets an Ack, with yiaddr = requested address.
>
>
>
> Nothing to say, this is the standard case, just for comparison purpose.
>
>
>
>
>
>
>
> 2) Use case 2:
>
> - Client C1 (not previously known from the server) sends a Discover,
> with a specific Requested IP Address (which is valid and free).
>
> - Client C1 gets an Offer but with yiaddr = another lease than the one
> he asked for
>
>
>
> The option Requested IP Address seems to be ignored. Is this on purpose ?
>
> (in the same use case, dhcpd will send back the Requested IP address)
>
>
>
> From RFC:
>
> If an address is available, *the new address SHOULD be chosen as follows*:
>
>
>
> o The client's current address as recorded in the client's current
>
> binding, ELSE
>
>
>
> o The client's previous address as recorded in the client's (now
>
> expired or released) binding, if that address is in the server's
>
> pool of available addresses and not already allocated, ELSE
>
>
>
> o *The address requested in the 'Requested IP Address' option, if that*
>
> * address is valid and not already allocated*, ELSE
>
>
>
> o A new address allocated from the server's pool of available
>
> addresses
>
>
>
>
>
>
>
> 3) Use case3:
>
> - Client C1 (not previously known from the server) sends a Request, with
> a specific Requested IP Address (which is valid and free).
>
> - Client C1 gets an Ack but with yiaddr = another lease than the one he
> asked for
>
>
>
> It seems that, if a lease has not been provided in an Offer response,
> then it cannot be specifically asked for in a Request.
>
> Is this on purpose ?
>
> (in the same use case, dhcpd will send back the Requested IP address)
>
>
>
>
>
>
>
> 4) Use case 4:
>
> - Client C1 sends a Request, with a specific Requested IP Address, which
> is invalid (not in a pool).
>
> - Client C1 gets an Ack (with a valid lease)
>
>
>
> From RFC:
>
> If a server receives a DHCPREQUEST message with an invalid 'requested
>
> IP address', *the server SHOULD respond to the client with a DHCPNAK*
>
> message
>
>
>
> Same question: is this behavior on purpose ?
>
> (in the same use case, dhcpd will send back an Nack)
>
>
>
>
>
>
>
> 5) Use case 5:
>
> Client C1 sends a Discover, is offered lease L1.
>
> Client C2 sends a Request, with Requested IP Address = L1.
>
> Client C2 gets an Ack, with yiaddr = requested address.
>
> Client C1 then sends a Request, with Requested IP Address = L1.
>
> Client C1 gets an Ack, but with yiaddr = a new IP address (L1 +1).
>
>
>
> It seems that as long as an IP address has been offered, anyone can
> ?grab? it in a Request.
>
> Is that the intended behavior ? shouldn?t be a lease reserved to the
> client to whom it was offered ?
>
>
>
>
>
>
>
> Thanks for your time.
>
>
>
> 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
>
------------------------------
Message: 6
Date: Thu, 11 Sep 2014 18:40:14 +0200
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Use cases and questions regarding lease allocation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I submitted: http://kea.isc.org/ticket/3592 to cover use case 4).
Marcin
On 11/09/14 18:34, Marcin Siodelski wrote:
> Nicolas,
>
> I think I may need to play with this some more, but so far I was not
> able to reproduce issues that you described in use cases 1) to 3).
>
> I made this simple test:
>
> - I setup two machines: one with the Kea server, another one with the
> dhclient.
> - I configured one subnet on the Kea server and associated with the
> interface to which the client was directly connected.
> - I started the dhclient and it obtained the lease with the address from
> the pool 192.0.2.100 - 192.0.2.200. The address it got was the first one
> from the pool: 192.0.2.100.
> - I stopped dhclient and Kea.
> - I removed the Kea lease file to simulate the case that the server
> doesn't know the client.
> - I modified the dhclient lease file and altered the address from
> 192.0.2.100 to 192.0.2.110 so as the dhclient requests the 192.0.2.110
> address specifically, not the 192.0.2.100 which would be allocated for
> the client even if not requested
> - I started up Kea
> - I ran dhclient using the modified lease file.
> - I checked with the wireshark that the dhclient sent Discover
> requesting the 192.0.2.110 in the requested IP address option. No other
> fields were set (e.g. ciaddr was set to all zeros)
> - The server responded with an Offer with yiaddr = 192.0.2.110 as
> requested by the client.
> - The client sent the Request with 192.0.2.110 and got Ack with this
> yiaddr from the server.
>
> The support for Requested IP Address option was added not so long ago. I
> wonder if you're using a recent version of Kea? Is this Kea 0.9-beta,
> Kea 0.9 relase or any other?
>
> Also, are you using a Memfile or some other lease database backend?
>
> Could you send a traffic capture?
>
>
>
> As for the use case 4). I was able to reproduce it and I agree that the
> issue exists. I'll submit the ticket for it. Thanks!
>
>
> Regarding use case 5).
>
> When the client C1 sends Discover and is offered an address it is going
> to be a rare case that the client C2 requests the same address before
> the client C1 requests it. It could happen if the client C2 was using
> this address before, and is renewing it and the server doesn't have a
> record of this client.
>
> If we wanted to address this use case we'd need to keep the collection
> of offered leases which brings additional complexity: when to release
> the offered address if client didn't get back for it, marking the
> address offered has performance penalties etc. So, in my opinion it is
> not worth an effort given that the case you're describing should be
> relatively rare.
>
> Marcin
>
> On 09/09/14 17:03, Chaigneau, Nicolas wrote:
>> Hello,
>>
>>
>>
>>
>>
>> I?ve done some more testing, and have questions related to some use
>> cases (which I compared to how dhcpd behaves).
>>
>>
>>
>> Note that the point of this mail is not to report defects ; I?m merely
>> trying to understand what may be design choices.
>>
>> (Nothing here is, strictly speaking, against the RFC, but some ?should?
>> and ?should not? are not enforced.)
>>
>>
>>
>> Anyway, here goes.
>>
>>
>>
>>
>>
>>
>>
>> 1) Use case 1:
>>
>> - Client C1 sends a Discover, is offered lease L1.
>>
>> - Client C1 sends a Request, with Requested IP Address = L1.
>>
>> - Client C1 gets an Ack, with yiaddr = requested address.
>>
>>
>>
>> Nothing to say, this is the standard case, just for comparison purpose.
>>
>>
>>
>>
>>
>>
>>
>> 2) Use case 2:
>>
>> - Client C1 (not previously known from the server) sends a Discover,
>> with a specific Requested IP Address (which is valid and free).
>>
>> - Client C1 gets an Offer but with yiaddr = another lease than the one
>> he asked for
>>
>>
>>
>> The option Requested IP Address seems to be ignored. Is this on purpose ?
>>
>> (in the same use case, dhcpd will send back the Requested IP address)
>>
>>
>>
>> From RFC:
>>
>> If an address is available, *the new address SHOULD be chosen as follows*:
>>
>>
>>
>> o The client's current address as recorded in the client's current
>>
>> binding, ELSE
>>
>>
>>
>> o The client's previous address as recorded in the client's (now
>>
>> expired or released) binding, if that address is in the server's
>>
>> pool of available addresses and not already allocated, ELSE
>>
>>
>>
>> o *The address requested in the 'Requested IP Address' option, if that*
>>
>> * address is valid and not already allocated*, ELSE
>>
>>
>>
>> o A new address allocated from the server's pool of available
>>
>> addresses
>>
>>
>>
>>
>>
>>
>>
>> 3) Use case3:
>>
>> - Client C1 (not previously known from the server) sends a Request, with
>> a specific Requested IP Address (which is valid and free).
>>
>> - Client C1 gets an Ack but with yiaddr = another lease than the one he
>> asked for
>>
>>
>>
>> It seems that, if a lease has not been provided in an Offer response,
>> then it cannot be specifically asked for in a Request.
>>
>> Is this on purpose ?
>>
>> (in the same use case, dhcpd will send back the Requested IP address)
>>
>>
>>
>>
>>
>>
>>
>> 4) Use case 4:
>>
>> - Client C1 sends a Request, with a specific Requested IP Address, which
>> is invalid (not in a pool).
>>
>> - Client C1 gets an Ack (with a valid lease)
>>
>>
>>
>> From RFC:
>>
>> If a server receives a DHCPREQUEST message with an invalid 'requested
>>
>> IP address', *the server SHOULD respond to the client with a DHCPNAK*
>>
>> message
>>
>>
>>
>> Same question: is this behavior on purpose ?
>>
>> (in the same use case, dhcpd will send back an Nack)
>>
>>
>>
>>
>>
>>
>>
>> 5) Use case 5:
>>
>> Client C1 sends a Discover, is offered lease L1.
>>
>> Client C2 sends a Request, with Requested IP Address = L1.
>>
>> Client C2 gets an Ack, with yiaddr = requested address.
>>
>> Client C1 then sends a Request, with Requested IP Address = L1.
>>
>> Client C1 gets an Ack, but with yiaddr = a new IP address (L1 +1).
>>
>>
>>
>> It seems that as long as an IP address has been offered, anyone can
>> ?grab? it in a Request.
>>
>> Is that the intended behavior ? shouldn?t be a lease reserved to the
>> client to whom it was offered ?
>>
>>
>>
>>
>>
>>
>>
>> Thanks for your time.
>>
>>
>>
>> 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
>>
> _______________________________________________
> 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 6, Issue 7
*************************************
