Re: [Kea-users] DHCPv4 - respond to option 108 without allocating leases

[Tomek Mrugalski]

On 22.05.2024 12:57, Francis Dupont wrote:
> Looking the RFC 8925 to try to understand how it is supposed to work...
> I think you should add a pool and have the client to ignore the offered
> address (it is the only MUST in client and server behaviors which can make
> the feature to work). I leave further details to Tomek who is one of the
> authors...
The option 108 is partially supported by Kea. The option itself can be
configured and sent back to client. That part should work fine.

The RFC8925 also says that the server should send back a response
(DHCPOFFER or ACK) with 0.0.0.0 address. Kea doesn't allow that yet.
There's a ticket about it (#3094) and we hope to implement this
logic sometime soon.

For completeness, here's the relevant RFC text:

The server SHOULD NOT assign an address from the pool. Instead, it
SHOULD return 0.0.0.0 as the offered address. Alternatively, if offering
0.0.0.0 is not feasible -- for example, due to some limitations of the
server or the network infrastructure -- the server MAY include in the
DHCPOFFER an available IPv4 address from the pool, as per
recommendations in [RFC2131]. In this case, the offered address MUST be
a valid address that is not committed to any other client. Because the
client is not ever expected to request this address, the server SHOULD
NOT reserve the address and SHOULD NOT verify its uniqueness. If the
client then issues a DHCPREQUEST for the address, the server MUST
process it per [RFC2131], including replying with a DHCPACK for the
address if it has not been committed to another client in the meantime.

Hope that helps,
Tomek
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Deprecating libreload command

[Tomek Mrugalski]

Hi,

We're planning to deprecate and later remove the libreload command 
completely. The command was implemented a long time ago, in Kea 1.2.0 
when the hooks framework was being implemented and there were no hooks.


The original idea, to reload just the hooks and not the whole server 
configuration seem to never gained any traction.


Unless we hear some serious objections, the command will print a warning 
in Kea 2.3 and upcoming 2.4. Some time later in 2.5 it will be removed 
completely.


If you don't know what libreload is, feel free to ignore this message.
But if you really want to learn something that's about to go way, see:

https://kea.readthedocs.io/en/kea-2.2.0/api.html#ref-libreload

If you have any feedback on this, please post it ether here or in the
Kea#2693 ticket (https://gitlab.isc.org/isc-projects/kea/-/issues/2693).

Cheers,
Tomek Mrugalski
ISC
--
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA SUPPORT DHCPv4 OVER NETCONF

[Tomek Mrugalski]

On 06.05.2021 14:39, Tomek Mrugalski wrote:
> On 06.05.2021 09:26, Onur GURSOY wrote:
>> I saw this
>> example: https://kb.isc.org/docs/building-a-kea-testbed-with-netconf
>> <https://kb.isc.org/docs/building-a-kea-testbed-with-netconf>.
>>
>> I'm wondering one thing:
>> Is it possible to use kea dhcpv4 server with sysrepo with netopeer for
>> using over netconf ?
> It should be, although you'd need to use older sysrepo 0.8.7 version.
> There were some substantial changes in the sysrepo architecture when
> when jumped from 0.8.x to 1.3.x (with apparently no versions in between)
> and Kea hasn't been updated for it yet.
My mistake. That really should be 0.7.8. The installation instructions
may be a bit outdated, so some experimentation may be necessary. Section
21.2
(https://kea.readthedocs.io/en/kea-1.8.2/arm/netconf.html#installing-netconf)
has links to wiki that has CentOS 7 and Ubuntu 18 specific notes. Those
may possibly be useful.

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA SUPPORT DHCPv4 OVER NETCONF

[Tomek Mrugalski]

On 06.05.2021 09:26, Onur GURSOY wrote:
> I saw this
> example: https://kb.isc.org/docs/building-a-kea-testbed-with-netconf
> .
> 
> I'm wondering one thing:
> Is it possible to use kea dhcpv4 server with sysrepo with netopeer for
> using over netconf ?
It should be, although you'd need to use older sysrepo 0.8.7 version.
There were some substantial changes in the sysrepo architecture when
when jumped from 0.8.x to 1.3.x (with apprently no versions in between)
and Kea hasn't been updated for it yet.

There is a plan to update Kea to latest sysrepo. Not sure about the
schedule for this, am afraid, except that it will be done before kea 2.0
goes out. For details, see kea ticket #1077.

Cheers,
Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Hooks-libraries

[Tomek Mrugalski]

On 28.04.2021 18:29, Makhdoom Naeem wrote:
> I am working from home lab to learn about kea-dhcp server. I have
> configured kea-dhcp4 and mysql server. But I have faced some problems
> regarding hooks-libraries. How do I install and configure them?
Hi Makhdoom,

Many of the problems you are dealing with are well described in the Kea
ARM. Please take a look at it:

https://kea.readthedocs.io/en/kea-1.8.2/index.html

The easiest way to install Kea is to use native (DEB, RPM or APK)
packages. The pointers are in Section 3.1.

The hooks have the whole section dedicated to them - Section 16.

Good luck!

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Dhcpv6 with mysql (revision_id)

[Tomek Mrugalski]

On 10.03.2021 15:48, João Butzke wrote:
> Hi, im trying to insert a new dhcp6_subnet on the kea database, im
> getting this error: ...
> 
> The procedures and triggers are created on the mysql server, any ideias?
The schema for config backend is complicated, because it was designed
for Kea to be able to retrieve incremental updates efficiently, e.g.
when you have 1000 subnets configured, adding another one should be
fast. The unfortunate side effect is that it's tricky if you're trying
to fiddle with the DB manually.

There's a cb_cmds hook that makes it very easy to use. Yes, it's a paid
hook. API details here:
https://kea.readthedocs.io/en/kea-1.8.2/arm/hooks.html#cb-cmds-configuration-backend-commands

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Multiple mac-addresses for the same IP

[Tomek Mrugalski]

I was reviewing old posts and found this one. The original poster surely
moved on, but perhaps the answers will be of use to some readers.

On 24.06.2020 08:52, iztok Gregori wrote:
> We are in the process to migrate our ISC DHCPD servers to KEA (using
> mariadb as backend). Everything worked fine until we tried to insert 2
> different mac-addresses, belonging to a unique host (wifi and wired
> interfaces) with the same IP/subnet as we used to do on DHCPD. The
> insert returned and error:
> 
> Duplicate entry '2355692056-14010520' for key
> 'key_dhcp4_ipv4_address_subnet_id'
> 
> I've checked the database and saw that the
> 'key_dhcp4_ipv4_address_subnet_id' is a UNIQUE index, therfor having
> multiple mac-addresses for the same IP is not possible.
> 
> Now comes my questions:
> 
> - First, am I wrong to conclude that aving multiple mac-addresses for
> the same IP is not possible?
It was not possible. It's still not possible in the default
configuration, but now you can enable it *if* you really want to in
1.9.1 or later.

> - Second, if this is true what is the rationale behind it?
Because in normal deployment it doesn't make sense. Imagine this
scenario. Device 1 with mac1 comes on-line and gets the IP address.
Now, device 2 with mac2 comes on-line and... what exactly is Kea
supposed to do? It can't grant the address, because there's a lease for
a different interface. Kea has no way of knowing if the other interface
is the same device or not. You may say "I don't care, grant it", but
then the device 1 wouldn't know about this change and would continue to
use it. Kea has a conflict resolution mechanism for dealing with
"careless" admins that reserved an address that is used by another
device. (Careless is maybe not the best word as there are cases when
this makes sense). It works roughly as this. Device 1 has an address
leased, but it's reserved for device 2. Kea can't revoke it instantly,
so it waits for the device 1 to renew, then NAKs it. If the device 2
comes in before that happens, it gets a different address temporarily.
Anyway, if we tried to use that mechanism for the same address assigned
to multiple interfaces, it would kept flipping between them.

But there's a mechanism to possibly consider here. Kea 1.9.1 introduced
an ability to have multiple reservations for the same IP. The caveat
here is that user is supposed to ensure that only one of them will be
active at any given time. The use case it was developed for was a server
with 2 physical interfaces with only one of them being plugged.

https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.1

Finally, the whole logic can be flipped. Why do you need this anyway?
Having the same IP address assigned to two devices breaks the
fundamental rule of DHCP - once an address is assigned, it's your and
yours alone for the time it was granted to you.

> - Third, there is a workaround or a better solution for our problem (we
> like to have the same IP for the same host regardless if it's on
> wireless or wired)?
See above. Also, make sure you test it thoroughly for case when both are
connected. I think the addresses will keep flipping.

> - Third and a half, changing the index to NON unique is a possible
> workaround? What are the consequences?
See 1.9.1. For earlier versions, this is asking for trouble. Kea code
makes some assumptions, such as "there's unique index, so we can assume
there's at most one address returned for a query". If you start tweaking
schema, all bets are off.

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Client class in host reservation

[Tomek Mrugalski]

Hi Maria,

Hope you're doing well. Apologies for not responding earlier. We looked
at the issue and it seems the code treated the client classes
differently for options and fixed fields, such as boot-file-name. This
problem manifested itself if a packet belonged to two classes and you
had the values defined in both. Anyway, this has been fixed now and
released in 1.9.5. Would you be willing to check if this updated
behavior address your needs? Also, if you're interested, the
improvements were done in ticket #1672. You can see the details here:
https://gitlab.isc.org/isc-projects/kea/-/issues/1672

If it doesn't, can you open a new ticket for this?

Hope that helps,

Tomek

On 11.12.2020 17:42, Maria Hrabosova wrote:
>
> Hello,
>
> I have a question about reserving client classes to hosts. Let's have
> two client classes and one host reservation as follows:
>
> /{//
> // "name": "class1",//
> // "boot-file-name": "file1",//
> //}, /
>
> /{//
> // "name": "class2",//
> // "boot-file-name": "file2",//
> //},/
>
> //
>
> /...//
> /
>
> /{//
> //    "hw-address": "aa:bb:cc:dd:ee:ff",//
> //    "client-classes": [//
> //        "class2"//
> //    ]//
> //},/
>
> Intuitively, I would expect it to be enough to specify class2 in the
> host reservation in order to make the host get the boot-file-name from
> class2. But it gets it from class1. Inspired by
> http://kea-users.7364.n8.nabble.com/Kea-users-client-classes-for-a-particular-MAC-Address-of-a-CPE-td843.html,
> I added the mac address of the host to the class test. Then the client
> got the option from class2 as I wanted.
>
> /{//
> // "name": "class2",//
> // "test": "pkt4.mac == 0xaabbccddeeff",//
> // "boot-file-name": "file2",//
> //},/
>
> I've been wondering, what is the purpose of putting the client class
> to the host reservation, if I have to put the client's MAC address to
> the class test anyway. Can anyone clarify?
>
> Thanks in advance.
>
> Best regards,
>
> Maria Hrabosova
>
>
> ___
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA instances with shared database

[Tomek Mrugalski]

On 12.12.2020 10:55, Emile Swarts wrote:
> Thanks for getting back to me. My assumptions about the in-memory
> state was largely based on this conversation:
> https://lists.isc.org/pipermail/kea-users/2017-December/001528.html
>
> Also point 4 on this page states:
> (https://kb.isc.org/docs/kea-performance-optimization)
>
> /"Avoid shared lease backends. When multiple Kea servers share a
> single lease backend (e.g. with a cluster of databases serving as the
> lease backend with multiple Kea instances sharing the same pools of
> addresses for allocation), they will run into contention for assigning
> addresses. Multiple Kea instances will attempt to assign the next
> available address; only the first one will succeed and the others will
> have to retry."
> /

Ah, that makes sense. That comment was in the context of incorrect
statistics. A lot has changed since 2017. The underlying problem in that
discussion (two Kea instances getting invalid statistics) is now solved.
The problem there was that each instance set allocated addresses
statistic at start-up and only increased or decreased it based on its
own allocation. This was causing weird problems with statistics,
reporting inaccurate data, such as negative number of allocated
addresses. This was only statistic reporting problem. It was fixed a
while ago with the stat_cmds hook. Another aspect that changed is that
Kea is now multi-threaded.

>
> The design I'm trying to achieve:
>
> 1. Multiple KEA instances (AWS ECS Fargate) sitting behind an AWS
> Network Load Balancer, sharing a single mysql backend
> 2. Horizontal scaling of these instances up and down to accommodate load
> 3. All instances are provisioned with the same configuration file
> (pools, subnets .etc)
> 4. Zero downtime deployments by removing instances and having the load
> balancer redirect traffic to remaining instances
>
> My concerns are mainly around race conditions and the iterator to find
> the next available IP to hand out.
> Does it sound like the above could be achieved?

In principle, Kea does this when needs to assign a new lease:

1. pick the next address as a candidate, check if it's available.

2. if it's not available, go back to step 1.

3. If the address is available (no lease, or expired lease that can be
reused), attempt to insert a lease

4. If the lease insertion succeeds, great! We're done.

5. If the lease insertion fails (because some other instance took it
first), Kea instance understands it lost a race and moves back to step 1.

That last step should solve many problems. If there's a race and one of
the instances loses, it will repeat. This is somewhat inefficient, but
in return there's the possibility to set up arbitrary number of instances.

Now, you need to look at your "single mysql backend". The setup you
described will protect against Kea failures, but what about mysql
service failure? Is this a single point of failure? If yes, is this
acceptable risk for you? If this is a cluster, make sure that 2 Kea
instances connected to different nodes are not able to allocate the same
address. Whether this is possible or not depends on the cluster and how
it ensures consistency. Am afraid I don't have enough experience with
clusters to be more specific here. Sorry.

In any case, I'd be very interested in the results you'll get with this
setup. Feel free to share on or off the list.

Thanks and good luck,

Tomek


___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA instances with shared database

[Tomek Mrugalski]

On 11.12.2020 18:12, Emile Swarts wrote:
> I've looked at implementing multiple KEA instances with a shared database.
> I realise that this current setup will hand out overlapping IPs because
> the leases are stored in memory not in the database.
Where did you get this impression from? This is mostly incorrect. If you
configure Kea to use a database to store leases, Kea will never cache
anything in memory and will always do a DB lookup before assigning
anything. The only way I can think of making Kea to keep the leases
"stored in memory" would be using memfile as lease backend, but then Kea
would never look up leases in a DB.

> I'm in the process of adding KEA HA, but just wanted to confirm that
> there is no way to force a lookup in the database to find the next
> available IP before committing to this approach.
Kea doesn't work the way you think it is. Kea always looks up the lease
database and never keeps any memory cache of it.

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea-packaging

[Tomek Mrugalski]

On 16.11.2020 22:18, Dirk Laurenz wrote:
> i found the kea-packaging repo and especially the Debian files there. I
> want to use them for building a kea dep package für Debian buster on
> armhf (Raspbian).
> 
> Is there any short tutorial how to use it?
Not really. Vicky pointed out a KB article, but it's more about how to
use the packages that are already built.

The kea-packaging repo contains the source files ISC uses to build
packages that are available on https://cloudsmith.io/~isc/repos/

Those build both open source and premium code. They won't work out of
the box. However, I think cutting out the premium component should be
reasonably easy.

This repository is provided on best effort basis.

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] dynamic router options in reply

[Tomek Mrugalski]

You can use flex-option for that. See
https://kea.readthedocs.io/en/kea-1.7.9/arm/hooks.html#flex-option-flexible-option-for-option-value-settings

The expression you are looking for should be very simple: "pkt4.giaddr"
if you want to use the giaddr field or "pkt.src" if you want to use
source IP address of the packet.

Tomek

On 17/07/2020 08:08, Anatoliy Kushner wrote:
> Hi , if we have network with multiply gw(relay) is it possible for kea
> return router (option 3) field based on giaddr ? 
> 
> should be something like this
> 
> "option-data":[
>         {
>           "name": "routers",
>           "data": relay.ip-address
>         },
> ]
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA-ANTERIUS - WEB INTERFACE

[Tomek Mrugalski]

On 15.07.2020 15:41, José Luís wrote:
I really took a look on "stork" and it's really powerful. But what I 
want is something simple, just to view, not monitor, like a simple 
localhost in the kea-machine. 
So you want to run everything locally? You can deploy stork agent and 
server on the same machine as Kea.


What sort of information would you like to view? Right now we can show 
networks, subnets and reservations. A basic log viewing coming in 
August. Leases are next after that.


Stork being actively developed and understanding what users feel is 
missing there is important. Obviously, Stork is still in its early days 
and there are lots of missing features. But we're adding new stuff quickly.


I also looked at the kea-anterius project 
and it looks softer, however it hasn't been updated for more than two 
years. I'll keep searching or maybe try to built something by my own. If 
It was a GSOC project and the student involved moved on to other things. 
Roughly a year ago we looked at it briefly and decided that there's too 
many things that require rewriting and decided to start from a clean 
slate. That's how Stork came to be.


Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Looking for QA/Support engineer for Kea

[Tomek Mrugalski]

Hi there,

If you've been using Kea, feel competent on it and would like to help it
prosper, here's something you may find interesting.

ISC is looking for a full-time QA/support engineer for Kea. We want a
tinkerer who is interested in using their lab skills to support our
users. Attention to detail, and a methodical approach are critical.

The primary software of interest will be Kea, with some sporadic
exposure to Stork, ISC DHCP and BIND 9. This is a x§remote job.

Details:
https://isc.recruitee.com/o/qasupport-engineer-for-dhcp

Cheers,
Tomek Mrugalski
ISC

___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] isc_kea: Reuse same IP for a host

[Tomek Mrugalski]

Hi,
Kea does not allocate anything when processing SOLICIT. It only picks an 
address, does all the checks (checks if there's a reservation for this 
specific client, that the address is not used by anyone else, not 
reserved, etc) and sends it back in ADVERTISE.


The client is supposed to send the address it got in ADVERTISE in its 
REQUEST and under normal circumstances Kea should then assign it. It was 
implemented that way for two reasons. First, the RFC8415 says the 
address should be allocated when REQUEST is received (there's good 
explanation for that in the RFC). Second, there's a performance gain. If 
there are multiple servers, all of them will send back ADVERTISES and 
client will pick only one.


If you really want to enforce that client always gets the same address, 
you have several options:


1. use rapid-commit. If you can turn rapid-commit on your clients, 
they'll send solicit and kea will allocate the address and send back 
REPLY (skipping the ADVERTISE/REQUEST phase).


2. you could define reservation for your host. Kea then would always try 
to use it before using an address from dynamic pool.


3. technically, solicit processing and request processing is very 
similar. Internally, they differ with fake_allocation flag, which is 
true for solicit and false for request. You could patch the code or 
write a hook that would always set the fake_allocation to false, 
effectively doing lease allocation on solicit. Not really RFC compliant, 
but it would work.


There's probably couple other things you could do, but those are the 
most obvious ones.


Hope that helps,
Tomek

On 02.06.2020 18:13, Mayank Tiwari wrote:

Hi,

   It may not be possible to use ::2 as both SOLICIT came at around 
same time. In first attempt it allocated ::3.  In the second attempt 
after reboot there was release of ::3. So how can I force it to reuse 
::3 instead of looking for new IP ::4 or ::5. kea code has following 
logic to reuse expire lease:


}else {

 // If the lease is expired, we may likely reuse it, but...
if (lease->expired()) {

 ConstHostPtr host;
if (hr_mode != Network::HR_DISABLED) {
 host = HostMgr::instance().get6(subnet->getID(), hint);
}

 // Let's check if there is a reservation for this address.
if (!host) {

 // Copy an existing, expired lease so as it can be returned
// to the caller.
Lease6Ptr old_lease(new Lease6(*lease));
ctx.currentIA().old_leases_.push_back(old_lease);

/// We found a lease and it is expired, so we can reuse it
lease = reuseExpiredLease(lease, ctx, pool->getLength(),
callout_status);

/// @todo: We support only one lease per ia for now
leases.push_back(lease);
return (leases);

}else {
 LOG_DEBUG(alloc_engine_logger, ALLOC_ENGINE_DBG_TRACE,
ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED)
 .arg(ctx.query_->getLabel())
 .arg(hint.toText());
}
 }
}



  Not sure why this logic is not getting triggered.

Thanks,
Mayank

On Tue, Jun 2, 2020 at 11:39 AM Mayank Tiwari > wrote:


Hi,

   We have requirement to use same IPv6 for the host after the
reboot of the host. What we have observed is that every SOLICIT
message results in allocation of new IP to the host.

First solicit:
2020-06-02 14:29:41.499 DEBUG [kea-dhcp6.alloc-engine/1]
ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available -
trying to dynamically allocate leases for client
duid=[00:03:00:01:**:45:34], tid=0x8be064

Second immediate solicit:
2020-06-02 14:29:43.103 DEBUG [kea-dhcp6.alloc-engine/1]
ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR no reservations found but leases
exist for client duid=[00:03:00:01:**:45:34], tid=0xcae8c5

   Both solicit allocate different IP. (First one ::2, Second one ::3)

  Similarly after reboot of host:

First solicit:
2020-06-02 14:35:38.020 DEBUG [kea-dhcp6.alloc-engine/1]
ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available -
trying to dynamically allocate leases for client
duid=[00:03:00:01:***:45:34], tid=0xac71b9
Second immediate solicit:
2020-06-02 14:35:38.023 DEBUG [kea-dhcp6.alloc-engine/1]
ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available -
trying to dynamically allocate leases for client
duid=[00:03:00:01:***:45:34], tid=0xac71b9
Both solicit allocates different IP (First one ::4, Second one: ::5)

   How can I override this behaviour in kea so that for the given
DUID it keeps using same IP address which is allocated for the first
time when it SOLICITS(::2 in this example).

Thanks,
Mayank



___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org

Re: [Kea-users] Storing host reservation in custom database

[Tomek Mrugalski]

On 31.05.2020 13:06, Marcin Romanowski wrote:
In my database I have that table name already so I can prepare view but 
this cannot be named 'hosts" but kea make SELECT on this table :(
Kea expects the tables to match exactly with the provided schema. There 
is no way to tell Kea to use a differently named table. And there won't 
be. Implementing such a thing would be asking for troubles. It would

be very easy to misconfigure it and also it would break down in some
non-obvious ways.

As others have suggested, please read section 4 of the Kea ARM.
The kea-admin tool uses schema scripts in 
src/share/database/scripts/{mysql,pgsql,cql} to create the schema. You 
may take a look at the

schema files if you want to understand the internals.

You may take a look at those.

Tomek
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Kea radius

[Tomek Mrugalski]

On 30/05/2020 17:01, Dajka Tamás wrote:

> Hi Marcin,
>
>  
>
> AFAIK, those are available after you purchase them:
>
>  
>
> https://www.isc.org/shop/
>
Premium hooks (host_cmds, flex-id and forensic-logging) can be purchased
as a package. However, several others (cb-cmds, RADIUS, subnet-cmds,
host-cache, class-cmds) are available  to support customers only. I
believe this is clearly stated in the Kea ARM.

Tomek

___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] i do not understand the concept of shared networks

[Tomek Mrugalski]

On 11/03/2020 14:40, Giso Kegel wrote:
> The most important sentence here is that
> "...In all of the above, there is no mention of Host Reservations..."
> for me it is exactly the use case that almost all the subnet definitions
> are host reservations.
I think you are confusing two things. Subnet definitions are NOT host
reservations. Subnets describe the topology of your network. Host
reservations describe special treatment for some devices in your network.

> The second point is
> "... it doesn't matter which subnet provides the address to a client,
> any/all should work just fine. ..."
> That's the point a server should only get an IP from his specific
> network via host reservation.
I don't fully understand your intention here. The following may possibly
help. If you want Kea server to only provide IP addresses to the devices
that are listed in your host reservations, you may want to skip pools
altogether.

Kea would then provide addresses only to those devices that you
explicitly listed. Note this has nothing to do with presence or absence
of shared networks.

> That means i do not need Shared Networks!?
If you don't understand what shared networks do, you absolutely don't
need them. In fact, the general recommendation is to not use shared
networks unless you have a good reason to do that. Without shared
networks the logic Kea has to deal with is simpler, so in general it's
more preferred.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea error code 1292

[Tomek Mrugalski]

On 07/03/2020 19:12, Satish Patel wrote:
> We are running kea-1.3 with mysql backend 
Sorry, I've stopped reading just there. 1.3 is ancient. There has been
4715 commits since 1.3.0 went out. Lots and lots of changes, including
many in MySQL and lease manager. Take a look at the changelog here:
https://gitlab.isc.org/isc-projects/kea/-/blob/master/ChangeLog

I strongly suggest to upgrade to 1.6.2, which is the latest stable release.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Question about libdhcp_lease_cmds.so library

[Tomek Mrugalski]

On 22/01/2020 11:57, DIN Support TRIMBORN Alexandre wrote:
> I have a question about premium libraries.
> 
> In the documentation, the Kea Premium Hooks package also provides the
> libdhcp_lease_cmds.so library.
Huh? Can you point to specific place where it says that? The whole
lease-cmds is open source. There's no premium version of it.

Maybe you mistaken that with host-cmds? That is part of the premium package.

> We want to use all the features of anterius to manage kea.
Would you be willing to elaborate on which specific aspects of anterius
you are interested in? Anterius was an GSOC experiment and it's no
longer developed. We're working on a similar, but much more scalable
solution. It's not usable yet, but we'd love to talk about features
people find most useful.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] About Stateless DHCPv6 settings.

[Tomek Mrugalski]

On 27.08.2019 14:16, Yoshihito Horigome wrote:
> I am trying to configure stateless DHCPv6 with reference to the
> documentation[1].
> 
> When set, "Sorry, no prefixes could be allocated." Is output, and a
> message indicating that allocation is not possible is output.

> 2019-08-26 20:40:39.271 DEBUG [kea-dhcp6.packets/35] DHCP6_PACKET_SEND
> duid=[00:03:00:01:6c:3b:6b:cf:9b:94], tid=0xcab890: trying to send
> packet ADVERTISE (type 2) from [ff02::1:2]:547 to
> [fe80::8e3b:6bff:fecf:9b94]:546 on interface eth0
> 2019-08-26 20:40:39.272 DEBUG [kea-dhcp6.packets/35] DHCP6_RESPONSE_DATA
> responding with packet type 2 data is localAddr=[ff02::1:2]:547
> remoteAddr=[fe80::8e3b:6bff:fecf:9b94]:546
> msgtype=2(ADVERTISE), transid=0xcab890

Hold on. That doesn't look like stateless at all. You didn't provide
full logs, but I guess your device must have sent SOLICIT, so Kea
reponds with ADVERTISE.

Stateless DHCPv6 is a simplified mode that does not involve assigning
anything (addresses or prefixes) that requires state tracking. Hence the
name stateless. It is used to provide additional configuration options,
such as DNS addresses or domain names. That kind of information is
requested by client sending INFORMATION-REQUEST message and the server
is supposed to reply with REPLY message.

The protocol spec says that if you need any addresses or prefixes, you
are doing stateful and therefore must send SOLICIT rather than INF-REQUEST.

So, if you want an address or prefix assigned, stateless is not for you.
Alternatively, if you want to use stateless, your device should not
request addresses or prefixes and send INF-REQUEST without any IA_NA or
IA_PD options (both are forbidden in INF-REQUEST).

> With statefull DHCPv6, it was possible to assign addresses to client PCs.
> Is there something wrong with the settings?
This looks like misunderstanding what stateless really is.

You may also take a look at
https://tools.ietf.org/html/rfc8415#section-6.1 or now obsoleted RFC3736.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] log the dhcp options the client requests

[Tomek Mrugalski]

On 22.08.2019 13:16, Munroe Sollog wrote:
> Just a bump to see if any progress has been made in allowing servers
> to log the options a client requests.
Thanks for bringing this up. That's interesting and a bit dangerous
request, especially if misconfigured.

What exactly would you like to see in the log? Content of PRL or ORO
options, i.e. a list of options being requested or the actual content of
all options the client sent in its messages?

Take a look at the loggers we currently have:
https://kea.readthedocs.io/en/latest/arm/logging.html#the-name-string-logger

In particular, you may look at kea-dhcp{4,6}.packets. If you're trying
to debug a client that his packets are rejects,
kea-dhcp{4,6}.bad-packets is something to look at. Also, there's
kea-dhcp4.options logger.

If none of those work for you, can you open an issue in gitlab?
https://gitlab.isc.org/isc-projects/kea/issues

Thanks,

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Extracting vendor-specific suboptions in hooks

[Tomek Mrugalski]

On 29/05/2019 22:32, Dave M wrote:
> My problem is with the hook. I want to dynamically assign the boot-file
> and server based on MAC address and model information (option 43,
> suboption 9) and potentially software version (option 43, suboption 6).
> 
> I will therefore need to extract these in pkt4_receive and then replace
> the boot-file and server according to my logic in pkt4_send.
> 
> I just don't know how to retrieve and parse the suboptions in option 43.
> Would anybody have sample code showing how I can extract these?
Questions about hooks development are generally better addressed at kea-dev.

You may want to take a look at
src/bin/dhcp4/tests/vendor_opts_unittest.cc and possibly also at
src/lib/dhcp/tests/option_vendor_unittest.cc Overall, you can do
something similar to this:

// check if there's option 43 in the packet.
Option4Ptr opt43 = pkt->getOption(DHO_VENDOR_ENCAPSULATED_OPTIONS);
if (!opt43) {
return;
}

// Get suboption 6 from the option 43.
Option4Ptr subopt6 = opt43->getOption(6);

// If you have option definitions, you may want to try casting to
// specific type. That way you'll be able to use type specific, such
// as getValue() returning a string for OptionString.
boost::shared_ptr str_subopt6 =
   boost::dynamic_pointer_cast(subopt6);

if (str_subopt6) {
 cout << "opt 43,subopt 6 value is " << str_subopt6->getValue() << endl;
}

You may want to take a look at src/lib/dhcp/option_*.h files.

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] IP address conflict handling

[Tomek Mrugalski]

On 23.05.2019 17:27, Pavel Zhukov wrote:
> Hello,
Hey Pavel,

> I'd like to raise this topic again.
> There is old thread
> https://lists.isc.org/pipermail/kea-users/2017-February/000850.html on
> this topic.
> 
> Looks like both server (kea) and client (NetworkManager [1] in my
> case) rely on each other on conflict detection and... nobody does it
> actually.  kea doesn't have it implemented and NetworkManager has dad
> disabled by default. So it's easy to have situation when kea simply
Hmmm. That looks like a violation of RFC4862, section 5.4.

Here's the applicable text:

 Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
  does not perform Duplicate Address Detection.

   -  Duplicate Address Detection MUST NOT be performed on anycast
  addresses (note that anycast addresses cannot syntactically be
  distinguished from unicast addresses).

   -  Each individual unicast address SHOULD be tested for uniqueness.
  Note that there are implementations deployed that only perform
  Duplicate Address Detection for the link-local address and skip
  the test for the global address that uses the same interface
  identifier as that of the link-local address.  Whereas this
  document does not invalidate such implementations, this kind of
  "optimization" is NOT RECOMMENDED, and new implementations MUST
  NOT do that optimization.  This optimization came from the
  assumption that all of an interface's addresses are generated from
  the same identifier.  However, the assumption does actually not
  stand; new types of addresses have been introduced where the
  interface identifiers are not necessarily the same for all unicast
  addresses on a single interface [RFC4941] [RFC3972].  Requiring
  that Duplicate Address Detection be performed for all unicast
  addresses will make the algorithm robust for the current and
  future special interface identifiers.

> sends it's own ip address to the client and NetworkManager uses it.
> (Yes I know it's kind of misconfiguration but very dangerous one)
> Is there any plans to implement conflict detection feature on server
> side at least as configurable option?
There's a ping check feature in ISC DHCP. It's IPv4 only. I know it's a
popular feature. We have not implemented it in Kea due to serious
performance implications. There are lots of people asking about Kea
performance. There are very few asking about ping check.

So I'm afraid we don't have any feature of this nature planned. As for
the specific case you mentioned that Kea could assign the address it has
configured on its interfaces... hmmm, this is something we could check,
as it doesn't require implementing the whole ICMP exchange, just looking
up local interface address. But would it be that helpful? There may be
statically (mis)configured devices in your network.

I'm not aware of any truly reliable way of doing this in IPv6 (except
the hosts actually following RFC4862). There is no strong requirement
for the DHCPv6 server to even have routing configured. The DHCPv6 by
default operates on link-local addresses and links farther away are
reached one hop at a time via relay. The server could be configured to
assign ULAs and don't even have routing configured to the class it
assigns. And then there are more exotic environments like NBMA links.

So, how do you propose such a solution could work?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] use of option 82, relay4[1].hex

[Tomek Mrugalski]

On 23/05/2019 09:41, agiimaa.b wrote:
>  "test": "relay4.[1].hex == 485754435096C50A",
485754435096C50A is being interpreted as decimal number.
Try this: relay4.[1].hex == 0x485754435096C50A

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Kea 1.5 Package Issues in Fedora Server 30

[Tomek Mrugalski]

On 26/04/2019 14:28, Brant Ian Stevens wrote:
> I filed a bug report a few weeks ago, and forgot to cross-post to the list.
> 
> I ran into a couple of problems that I hope someone from the development
> team can take care of:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1699408
Hi,

This covers several things:

1. It requires the manual creation of directories for interprocess sync
lockfile
That's a valid concern. This looks like the same issue as reported here:
https://gitlab.isc.org/isc-projects/kea/issues/359

There is also similar issue reported here:
https://gitlab.isc.org/isc-projects/kea/issues/538

We hope to fix both of them in upcoming 1.6-beta.

If they cover your problem, can you comment on one or both of them? If
not, can you open a new issue in out Kea gitlab:
https://gitlab.isc.org/isc-projects/kea/issues/new

2. It does not include all the previously-supported database backends,
breaking the service upon upgrade from Fedora Core 29 Server.

This is a packaging problem. Kea still does support MySQL, PostgreSQL
and Cassandra backends. It seems the Fedora 29 packages were built with
PostgreSQL and Fedora 30 were built without it.

Note that the command switch passed to configure to enable specific
backend was --with-dhcp-pgsql, --with-dhcp-mysql and it is now simpler
--with-pgsql and --with-mysql. The older switches are obsolete now (they
work, but there's a warning produced).

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

[Tomek Mrugalski]

On 18/04/2019 15:16, Alberto Pollastro wrote:
> I agree with Kari; it could be useful to have an option which permits to
> ignore the DHCP DECLINE messages like the one present in ISC dhcpd
> ("declines" keyword in config file:
> https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html).
> Another option it could be to implement on server side a DHCP DECLINE
> per source MAC rate limiting (or a kind of Fail2ban for DECLINE
> messages) because usually the L2 switch support DHCP rate limiting
> accordint to the switch port.
We were thinking about rate limiting of various things, but never got
round to implement this mechanism.

As a crude workaround, you could try setting up
"decline-probation-period" to something very small, like 10 seconds or
less. But please keep in mind that this would be effectively disabling a
protocol feature that's there for a reason.

Also, if you want to do some experiments, disabling DECLINE handling on
the server side is a trivial code modification. Open up
src/bin/dhcp4/dhcp4_srv.cc and comment out line 1024:

// processDecline(query, ctx);

Note the side effect is that your buggy client will think the lease was
declined, will revert back to discover and the server will assign the
same lease again. This loop will likely repeat over and over again.

Depending on your situation this may be a better or worse workaround
compared to low decline-probation-period.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] [GSoC 19] Leasequery Project

[Tomek Mrugalski]

Hi Athreya!

Thanks for your interest in the project. Please see my earlier responses
on kea-dev to another student interested in the same topic:

https://lists.isc.org/pipermail/kea-dev/2019-March/000924.html

https://lists.isc.org/pipermail/kea-dev/2019-March/000927.html

Welcome to the Kea project!
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] 1.4 - limit subnet to static reservations/leases

[Tomek Mrugalski]

On 14.02.2019 15:37, ѽ҉ᶬḳ℠ wrote:
> The current dnsmasq ipv/4/ leases (still in place) supposedly showing
> client identifier, e.g.
> ff:a9:13:fb:9b:00:02:00:00:ab:11:f0:18:bd:02:af:a5:19:a1.
> Perusing online resources has not cleared up for me whether there is a
> correlation between DUID and client identifier, some sources hinting the
> client identifier containing the DUID?
Client-id MAY contain DUID. Clients (presumably dual stack) that support
this optional extension may use DUID with some extra information as
client-id. See RFC4361 for details, especially section 6.1. In principle
Kea supports that, but I think it was never thoroughly tested.

> Suppose such client identifier would be matching */client-id/* in the
> Kea conf?
Kea can be told to match client-id (the whole option) or duid (a subset
of the client-id option), depending on your configuration. See
host-reservation-identifiers and some examples of host reservations.

> Since client-id spoofing would appear more difficult than mac spoofing I
> would probably prefer client-id. Just have to check whether client-ids
> are indeed ephemeral.
Depends on what you're using to spoof it. It's a configuration option in
dhclient.

> Seems a bit a of cumbersome way to run first a dhcp server to gather
> client-id/DUID from its linux clients to utilise such for host
This complaint that is over 15 years old now. If you're really
interested in the bottom of this, here's a bit of DHCP history. The
concept of DUID was created back in around 2000. The problem people
working on a spec that eventually became RFC3315 wanted to solve was a
failure of NIC cards. In the 90s network cards were failing sometimes
and when replaced, the host appeared as completely new device. So they
thought a new type of identifier is needed that would survive changing a
MAC address. DUID can do that. And it's about the only thing is does
great...

Now, fast forward to more recent times when network card failures is a
rare event. On the other hand, we have VMs being cloned (with the same
DUID appearing on two clones), we have dual boot devices (which each OS
using different DUID) and then there are PXE devices that may use
different DUIDs for each stage. Even in the simplest of cases - a laptop
being booted for the first time - a vendor can't print DUID on the box
the same way they print MACs, simply because the DUID is usually created
on the first boot.

What's more there are currently 4 different types of DUID defined and in
actual use: LLT (MAC address + timestamp of first boot of the device),
LL (just MAC address + some fixed, well known duid type), EN (vendor
assigned) and UUID. RFC3315 preferred LLT. When IETF was updating DHCPv6
spec, we tried to alleviate the problem and RFC8415 no longer says that
LLT is the default choice, but there's no easy solution after 15 years
of implementations.

Personally, I would say the concept of DUID didn't withstand the trial
of time well.

> reservation matching. My network management preference though is ifupdown2.
As Jason has suggested, please consider simply using MAC addresses. You
can tweak Kea DHCPv6 to look at MAC addresses. I admit that those are
not directly available in DHCPv6, but there are several modes of
extracting them from incoming packet. This has been implemented many
years ago and I don't remember anyone complaining about that. For
details, see

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6

Another aspect you may possible look at to let you make a better DUID vs
MAC decision is a mechanism defined in RFC6939. It makes client's MAC
addresses available to the DHCPv6 server. It requires relay to support
it, but that's easier to do than upgrading your clients.

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] 1.4 - limit subnet to static reservations/leases

[Tomek Mrugalski]

On 14.02.2019 12:20, ѽ҉ᶬḳ℠ wrote:
> Though perhaps a bit off topic, please bear with me, I have been
> wondering about DUID in ipv4 since thought that it would be only
> applicable to ipv6?
That was the original idea. But then the reality kicked in. The primary
use case for DUIDs in ipv4 is to be able to match requests coming from
dual-stack devices.

> To my understanding the DUID would be provided by the dhcp client but I
> have not found way to figure the clients's ipv4 DUID, all linux distros,
> in order to use it for host reservation. Neither iproute2 nor ifupdown2
> seem to provide that information. Is there a way to harvest those ipv4 DUID?
Not sure. If the client supports it, as a last resort you can capture
the traffic and extract its client-id option. That's not exactly a
convenient way, I admit that. I found a discussion about it on systemd
github: https://github.com/systemd/systemd/issues/394. It mentions some
pull requests that apparently were merged. You may want to look around
that area and see if anything comes up.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] 1.4 - limit subnet to static reservations/leases

[Tomek Mrugalski]

On 14.02.2019 09:14, ѽ҉ᶬḳ℠ wrote:
> being in the process of migrating from dnsmasq I have been looking for
> an option in Kea to limit a particular subnet to static leases only,
> something similar to dnsmasq's > dhcp-range=static <, but after having
> perused the Kea admin documentation could not trace such?
So you want a subnet without any dynamic allocation, just serve the
clients that have reservations?

Simply don't define dynamic pools. That should do the trick.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Seffault Crash

[Tomek Mrugalski]

On 11.02.2019 15:43, Justin Bail wrote:
> Over the weekend we had a segfault error that locked up the entire VM. 
I've very sorry to hear that.

Can go to https://gitlab.isc.org/isc-projects/kea/issues, click new
issue and select template bug_report and answer the questions there.

If you plan to attach anything you don't want to be publicly viewable,
make sure you the confidential checkbox.

> Background:
> 
>   * Mysql backend on separate server
>   * ~300 leases total
>   * 3 months of up time
>   * ~4 host reservations
>   * Using Flex ID to change client ID to option 82 identifier
>   * Using DDNS to strip bad hostname characters
>   * Sql connection wait timer set to 1
>   * Dhcp socket type set to udp
>   o Was RAW when issue occurred.  
Thanks for sharing this information. That doesn't look like a
particularly stressful or complex configuration. When opening a bug
report, please also include the following crucial information:

- which kea version you used
- what OS (linux of bsd distro, which version)
- whether you compiled Kea from release tarball, got it from a package
or perhaps got source from git
- include your full config file (removing database passwords is
recommended).

This should be all covered by the bug_report template in gitlab.

> Segfault error from journctl:
> 
> *Feb 09 01:49:03 harpy kernel: kea-dhcp4[12641]: segfault at 10 ip
> 7fabaad99918 sp 7fff8ff4b690 error 4 in
> libkea-dhcp++.so.8.0.0[7fabaad39000+fc000]*
Sadly, this information is useless if we don't have extra information.

Is there a core dump? If there is, please attach the core dump to the
bug report.

Thanks for reporting this issue,
Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] ddns fails with powerDNS (Failed PreRequisites check)

[Tomek Mrugalski]

On 06.02.2019 18:03, Jason Guy wrote:
> records. It would be nice if there was a knob in kea-dhcp-ddns
> configuration to turn off the creation of DHCID records.
Can you submit a request for this?
https://gitlab.isc.org/isc-projects/kea/issues

I can't make any promises yet, but it is likely that Kea 1.7 will cover
various DDNS tweaks and features.

Thanks,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Raspberry PI 3B+ as DHCPv4 & DHCPv6 HA pair - auto start issue

[Tomek Mrugalski]

Hi Russell,

One CA is able to interface with dhcp4 and dhcp6. Why do you want to run
two of them? Is this about listening on v4 and v6 sockets? We could talk
about some extension to control agent, so it would maintain two sockets.
Would such a thing address your problem?

Also, for the specific issue, the location of pid file can be controlled
with KEA_PIDFILE_DIR environment variable. Since you're using packaged
version, the alternative does not appeal to you, but if you compile Kea
yourself, you can also alter localstatedir in configure script.

On 25.01.2019 18:25, russell aspinwall wrote:
> It would be nice to configure two kea-ctrl-agents with in a single
> file with processes spawned to handle the different ip/socket combinations
>
> "Control-agent": {
>     "http-host": "192.168.26.248",
>     "http-port": 8080,
>
>     "control-sockets": {
>     "dhcp4": {
>     "socket-type": "unix",
>     "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>     }
>     }
>  },
> "Control-agent": {
>     "http-host": "fd22:318a:1212:1:8456:1466:9675:5991",
>     "http-port": 8081,
>
>     "control-sockets": {
>     "dhcp6": {
>     "socket-type": "unix",
>     "socket-name": "/tmp/kea-dhcp6-ctrl.sock"
>     }
>     }
> 
> },

That's not a valid JSON. So no, that's not possible.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] DHCPv6 Reconfigure?

[Tomek Mrugalski]

On 17.12.2018 22:59, Templin (US), Fred L wrote:
> Hi Tomek,
> 
> Thanks for the response. It sounds like there are no technical issues that 
> would
> prevent the implementation of Reconfigure in kea - rather, it is a 
> prioritization
> and resource question which is always the case for any large software 
> distribution.
> Do I have that right?
Correct. There are no technical objections. On the contrary - this is a
feature we'd very much love to get. Unfortunately, our resources are
limited, so we are try to focus on features that are requested most
frequently.

And reconfigure is rarely requested, which is a shame. It's a good
mechanism. IMHO the fundamental mistake was made years ago when support
for this feature was made optional while defining RFC3315. Since clients
can chose to not implement (and most implementors go that way), network
administrators can't rely on the feature. This in turn made server
implementors to not implement it, because few people ask for it. There
are some deployment environments, such as cable networks, where docsis
3.0 mandates reconfigure implementation.

I proposed to make it mandatory when DHC was working on RFC3315bis, but
sadly my proposal was rejected.

> I do not have a pressing need for the functionality at the moment, but that 
> may
> change as we get further down the road in 2019. For now, I just wanted to
> verify that there are no technical issues that are preventing the 
> implementation
> and I think I have my answer.
Again, this is correct. We'd love to get this feature. There are some
undecided aspects, such as how to define management interface for it,
but overall the feature is sound and we want it.

Speaking of the interface, there are many ways how a reconfigure could
be implemented. The easiest will be to send reconfigure to a single
client, triggered by a command, say, client-reconfig. We'll surely get
some form of reconfigure all clients and it looks like something in
between those two. Perhaps a mechanism to say "all clients in subnet X"
 or maybe "clients having an address from pool Y" are to be reconfigured.
Anyway, that's something to think about.

Thanks for asking about this feature. I really hope we'll get it
implemented soon.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] DHCPv6 Reconfigure?

[Tomek Mrugalski]

On 17/12/2018 17:21, Templin (US), Fred L wrote:
> Hi, does kea have support for DHCPv6 “Reconfigure” messaging?
No. One of the GSOC projects in 2019 was to implement reconfigure. That
project made significant progress and implemented major parts of the
code, but there is still non-trivial part to be reviewed and to be written.

> And, are there any client implementations that exercise it?
AFAICT reconfigure is mandatory in docsis 3.0, so any cable modem that
claims docsis 3.0 compliance is supposed to support it.

The only other implementation I'm aware of that supports it is Dibbler.
I happen to be an author of that project. However, it was my hobby
project I was doing in my spare time and it is not longer supported (for
any stretch of that word). If you want to do some experiments with it
and it works - great. If it doesn't... there won't be anyone to help.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Can't connect to Cassandra

[Tomek Mrugalski]

On 14/12/2018 11:26, Hreiðar Jóelsson wrote:
> Hi, has anyone seen this error before? I‘m trying to connect to
> Cassandra. I did build KEA using the latest Datastax driver from github.
The latest means 2.11? I haven't updated my cassandra setup in a while
and I'm still on 2.8.

Can you submit a bug for this in our gitlab? Please make sure to clearly
say OS, Datastax driver and Cassandra versions.

Thanks,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] redis DB support

[Tomek Mrugalski]

On 07.12.2018 05:50, Chinnapaiyan, Nagamani wrote:
> Is there any plan to support redis DB as backend for kea dhcp server?
> Freeradius uses it to get more faster rate…
Not at this time.

Adding additional backend brings in a lot of initial integration work
and then ongoing maintenance effort that is significant. That ongoing
effort is much bigger than the integration. It's easy to not realize how
much extra work an extra backend brings in. We need to make sure the
code builds on all systems we're trying to support, our test executions
become longer and slower. And then, every time we touch anything related
to database backends, it would take at least 33% more time, because we'd
need to apply changes to 4 databases rather than 3.

On top of that there's also the question of how easy or difficult it is
to work with specific database. REDIS is not a relational db and this
raises warning signs all over. We experienced similar problem with
Cassandra. It's a non-relational database, so you can't have typical
relational tables there. In practice that means that every time we
change or add something to a backend, we effectively do it twice: once
for mysql (then copy it over to postgres, which uses different data
types, but the overall approach is very similar) and then scratch our
heads how to stuff things into Cassandra. And Cassandra more often than
not takes more time than mysql and postgres combined...

There's also the question of Redis similarity to memfile. Memfile is our
own in-memory implementation with disk consistency. Sure, there may be
some benefits of Redis compared to memfile, but are they significant
enough to justify the effort?

And finally, there's the business aspect here. If we were approached by
a large existing or prospective customer and they requested a new
database support, we would consider it. But it's a decision we wouldn't
take lightly.

Hopefully this a bit long explanation is better than a single "no".
Sorry if this is not exactly what you hoped to hear.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] lease4 table additional connection to mysql

[Tomek Mrugalski]

On 04.12.2018 13:06, sven.roeh...@web.de wrote:
> currently I'm working on a hook for kea dhcpv4 to differentiate between
> privileged/unprivileged leases.
>  
> I'm reading the hardware address and relay agent id (dhcp option 82) out in
> the pkt4_send hook and save it for use in the pkt4_receive hook.
> In the latter I want to check if the hardware address exists in the lease4
> table or in case it doesn't, check for the relay agent id. Next step would
> be to set an privileged/unknown class depending on the existance of the
> check.
>  
> My question is, is there a more elegant way to check if a lease exists than
> using an additional connection to the mysql server and querying the table?
> E.g. using the kea engine to check?
It depends on the query. You may use existing leasemgr:

#include 
#include 

auto a =  LeaseMgrFactory::instance().getLease4(hwaddr);
auto b =  LeaseMgrFactory::instance().getLease4(hwaddr, subnet_id);

Take a look at the LeaseMgr class interface in lease_mgr.h. There are
several different queries exposed. If they cover what you want to do -
great.

Also, if you need to store anything with existing leases, you may want
to take a look at user-context. 1.5.0beta1 introduced support for this
in leases. The concept is simple: you're able to store any data (within
reason, IIRC there's 8KB limit) with leases as long as it is in JSON format.

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA dhcp and BIND with ddns

[Tomek Mrugalski]

On 04.12.2018 11:31, Thomas Andersen wrote:
> We are already live with kea DHCP and have always used BIND for dns.
Great!

> Is it possible to use DDNS to make client host names resolve in BIND dns?
Sure. You need to do start dhcp-ddns daemon (often nicknamed d2) and
tweak couple knobs in DHCP server to actually send name change requests
to that deamon. It will then send DNS updates to your DNS server, be it
BIND or any other RFC2136 compliant server.

See Sections 8.2.16 (DDNS for DHCPv4), 9.2.21 (DDNS for DHCPv6) and 12
(DHCP-DDNS server):
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp-ddns-server

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Remote debugging in KEA

[Tomek Mrugalski]

On 02/11/2018 15:50, Hreiðar Jóelsson wrote:
> thanks, I was not able to get gdb working remotely with Clion but I 
> managed to get some trace of the crash by running it locally on the 
> server. The problem is that I’m not sure what to make of it 
See some tips below.

> Thread 1 "kea-dhcp4" received signal SIGSEGV, Segmentation fault.
> 
> #0  0x7ffe4c2338b8 in ?? ()
> 
> #1  0x7f5f823fb960 in isc::dhcp::LibDHCP::packOptions4 (buf=..., 
> options=std::multimap with 8 elements = {...}) at libdhcp++.cc:805
This is the part of the code that's segfaulting:

for (OptionCollection::const_iterator it = options.begin();
 it != options.end(); ++it) {

Line 805:it->second->pack(buf);

This is a packOptions4 method that iterates over DHCP options stored in
Pkt4 packet. It is trying to pack (prepare on-wire representation of the
options). The option collection is a multimap that stores each option
as . The first entity is option code, and the
second is supposed to be a smart pointer to Option instance (or a class
derived from Option). It looks like one of the options is not
correctly added to the packet. Since this is the first time such a
problem is reported, I suspect is it your hook that adds the option
in some incorrect way. Can't say what's wrong for sure - perhaps you
added raw pointer, instead of OptionPtr (which is a shared pointer),
maybe it's null or the underlying object is misimplemented.

If I were you, I'd start with printing out it->first before calling.
Something like this added before line 805:

std::cout << "Packing option " << it->first << ", the pointer is " <<
it->second << std::endl;

At the very least, this will print out the code of the option that
causing the crash. Hopefully this will give you some pointers.
If it->second is not null, you may call it->second->toText(0) and print
out the result.

> I ‘we discovered that the server crashes when I feed in DHCP option 
> using isc::asiolink::IOAddress, where the type is ipv4-address, like 
> option 6 – domain-name-servers. Maybe someone can show an example of
> how one should go about overwriting those kinds of options.
And here's probably the reason. Please take a look at
src/lib/dhcp/tests. There are many examples there. A good file to look
at is option4_addrlist_unittest.cc

Finally, this kind of questions are better suited for kea-dev. Average
users are probably not interested in internal workings of kea.

Speaking of remote debugging, perhaps you want to set Kea running on
your local dev system? You can consider running perfdhcp to generate
client traffic. It's not perfect and has many shortcomings, but it may
be something to look at.

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Kea hackathon in Gdansk

[Tomek Mrugalski]

There's a Kea hackathon coming up!

Kea users, existing and prospective contributors and basically anyone
who wants to talk with Kea engineers in a not so formal setting are
invited to join us in Gdansk, Poland on Oct 11th and 12th for a Kea
hackathon.

If you ever wanted to start contributing to the Kea project or the
feature you'd like to see isn't really on the roadmap and you wanted to
make your case, here's your chance.

The overall plan is to spend two days talking about new features,
designing, coding, testing and hacking anything Kea related. The rough
idea is to focus on two upcoming new features that we hope will make it
into 1.5: ability to store configuration in a database and YANG/NETCONF
support. We'll be more than happy to cover basically any other Kea
related topics if there's interest and people on site willing to discuss it.

The exact location is TBD, but it's likely we'll be able to use Gdansk
University of Technology facilities.

More details:
https://gitlab.isc.org/isc-projects/kea/wikis/kea-hackathon-gdansk

If you plan on joining, please send a note to the list (or to me
directly if you're that shy) and put your name on the list on wiki. It's
still well over a month away. If you don't have anything more urgent
planned, we'd be happy to talk, design, hack code and perhaps have some
beer together.

Thanks and hope to see you in October in Gdansk!

Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] DHCP4_PACKET_NAK_0001 error for DHCPDISCOVER

[Tomek Mrugalski]

On 09.08.2018 15:50, McBride Lawrence wrote:
> Suffice it to say I needn’t have asked the question if I had looked
> closer at all of the error messages because it was obvious that the
> subnet was not recognised by the server due to yet more f*%g config
> file syntax errors with misplaced commas, brackets etc.
No worries. Kea parsers are rather strict and unforgiving. There's some
initial pains to endure, but once you're past them, your config file
will be cleaner.

> I really need to invest in a better .vimrc for highlighting and bracket
> matching or move to another editor that is more friendly.
Couple suggestions: Use indents in your config. Use on-line validators
to check syntax. Run kea with logging set to stdout, so you immediately
see the errors. If you're completely lost, start with one of the config
examples that comes with Kea. There's around 40 of them. Look in
doc/examples directory. Start from the example and tweak it bit by bit
until you get to where you want to be.

Also, if you're interested, ISC offers professional support that
includes config reviews. See https://www.isc.org/mission/contact/.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] REST calls 'config-set'

[Tomek Mrugalski]

On 26.07.2018 01:35, Phoebe Lee wrote:
> When issuing the 'config-set' rest API command to the CA to write new
> configurations to our server, is there a method of retrieving the new
> configurations (written by the rest-api)? 
> 
> After issuing a 'config-set' we are not able to issue a 'config-get' as
> it says that our server may be offline.
If the config you pushed using config-set doesn't have a control-socket
entry in it or it's configured to a different path than your CA has
configured, you can shut yourself off.

If that's not the issue here, what does the kea log say?

Details available in Section 8.9 of the Kea User's Guide:
https://kea.isc.org/docs/kea-guide.html#dhcp4-ctrl-channel

Also, have you tried to call config-get first and then pushing back the
same config?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] [Kea] subnet or shared network selected for multiple relays

[Tomek Mrugalski]

Reviving an old thread, hopefully with some good news.

On 24/11/2017 17:46, Chaigneau, Nicolas wrote:
> I would like to configure a subnet shared by multiple relays, i.e. that
> would be chosen for several “giaddr” values.
> 
> If I’m not mistaken, this was not possible with the basic “subnet4”
> configuration prior to 1.3.0 (as parameter “relay” does not support a
> list of relays).
> 
> Can I achieve that with a shared network in 1.3.0 ?
No, but you can do it in 1.4.0.

The "relay": { "ip-address": "..." } syntax is now deprecated (but don't
worry, it will work for couple releases). A new syntax is as follows:

"relay": {
"ip-addresses": [ "10.0.0.1" ]
}

This should in principle work for shared networks, but it hasn't been
tested extensively. User reports more than welcome.

> I’ve read Kea admin guide but I’m not sure this is possible just with
> configuration.
The admin guide for 1.4.0 has its examples updated.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea 1.3.0 dying with mysql error

[Tomek Mrugalski]

On 18/06/2018 01:07, Satish Patel wrote:
> I have configured kea 1.3.0 with mysql and everything works but after
> few hours found kea is dead and spotted following error in log, I have
> check everything mysql running fine everything looks good in DB.
> 
> 2018-06-15 11:48:55.798 INFO  [kea-dhcp4.dhcp4/16020] DHCP4_STARTED
> Kea DHCPv4 server version 1.3.0 started
> 2018-06-15 12:01:29.048 ERROR [kea-dhcp4.dhcpsrv/16020]
> DHCPSRV_MYSQL_FATAL_ERROR Unrecoverable MySQL error occurred: unable
> to execute for  h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id,
> h.ipv4_address, h.hostname, h.dhcp4_client_classes,
> h.dhcp6_client_classes, h.dhcp4_next_server, h.dhcp4_server_hostname,
> h.dhcp4_boot_file_name, o.option_id, o.code, o.value,
> o.formatted_value, o.space, o.persistent FROM hosts AS h LEFT JOIN
> dhcp4_options AS o ON h.host_id = o.host_id WHERE h.dhcp4_subnet_id =
> ? AND h.dhcp_identifier_type = ?AND h.dhcp_identifier = ? ORDER BY
> h.host_id, o.option_id>, reason: MySQL server has gone away (error
> code: 2006). Server exiting now!
Translation to plain English: MySQL server has gone away (i.e. Kea
connection to MySQL server was terminated for whatever reason, DB
restart, temporary network failure, etc).

In this state Kea would be useless. It would not be able to answer any
packets as it couldn't check lease state, create new leases, extend
existing ones etc. Continuing in this state would give users a false
impression that the server is somehow functional. Therefore kea 1.3
terminates itself as soon as database failure is detected.

This has been improved in 1.4. Kea attempts to reconnect. If this
behavior makes you unhappy, please upgrade.

> 2018-06-15 12:01:29.055 INFO  [kea-dhcp4.legal-log/16020]
> LEGAL_LOG_FILE_CLOSED  @@Missing placeholder %1 for
> '/var/log//kea-forensic4.20180615.txt'@@
This is begign bug in our logging routines. I've submitted bug #5653 for
this. You can view (and possibly comment on it if you like) here:
https://kea.isc.org/ticket/5653

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] MySQL DB does not work when "lease-database" is set

[Tomek Mrugalski]

When talking to the Debian maintainer, you may also mention that 1.4.0
is around the corner. Unless we hit something very unexpected, it should
be released this Friday.

Tomek

On 13/06/2018 16:32, Kevin Olbrich wrote:
> Package version on debian is still 1.1.0 on all branches.
> I sent an email to the maintainer as 1.3.0 is the recommended release
> and 1.1.0 is some kind of "please do not use this anymore"-release.
> 
> PS: I am on MariaDB 10.2 on both server and client. This might be the
> problem. I did not fix the problem yet as all leases are static. I will
> look into this the coming weeks.
> 
> Kind regards
> Kevin
> 
> 
> 
> 2018-03-19 14:26 GMT+01:00 Jason Guy  >:
> 
> Hi Kevin,
> 
> What version of mysql are you using? I have no problems with mysql
> 5.7 (client and server). Also, have you initialized the database?
> 
> Finally, I assume you are using version 1.1 because that it the only
> version available on Debian Apt... I am still trying to have the
> maintainer take more of my patches, and push the 1.3 packages to the
> testing repo, but it is not going well. If anyone knows the
> maintainer for this package, or has any advice about how to get more
> traction with the debian maintainer, I would be grateful. I have
> done a lot of work to patch the 1.1 package to become the 1.3
> package, and I am using in my testing. But I would like to make this
> available to all. :)
> 
> Cheers,
> Jason
> 
> 
> On Mon, Mar 19, 2018 at 9:22 AM, Thomas Markwalder  > wrote:
> 
> Hello Kevin:
> 
> Kea is now up to version 1.3.0 with many new features added
> since 1.1.0 so you may wish to consider upgrading.  However, Kea
> 1.1.0 should function using MySQL for lease storage.  Kea
> servers can emit a great deal of logging detail, provided you
> have it enabled.   With sufficient logging enabled, you should
> see some sort of response from Kea to client packets.  Even if
> Kea elects to drop a packet, you should still it's arrival
> logged and an explanation for why it was dropped.
> 
> I would suggest, as a starting point that you dial up the
> logging detail.  The following logger configuration will give
> you maximum output to stdout (for more information on logging
> please see the Logging chapter in the Kea Admin guide):
> 
> 
> "Logging":
> {
>   "loggers": [
>     {
>   "name": "kea-dhcp4",
>   "output_options": [
>   {
>     "output": "stdout"
>   }
>   ],
>   "severity": "INFO",
>   "debuglevel":99
>     }
>   ]
> }
> 
> I have attached a log excerpt from a Kea 1.1.0 server I
> configured to use MySQL lease storage so you can see what to expect.
> 
> 
> 
> Regards,
> 
> Thomas Markwalder
> ISC Software Engineering
> 
> 
> 
> On 03/18/2018 06:02 PM, Kevin Olbrich wrote:
>> Hi,
>>
>> I set the following as my lease-db:
>>
>>   "lease-database": {
>>     "type": "mysql",
>>     "name": "dc_dhcp",
>>     "host": "192.168.30.2",
>>     "user": "dc_dhcp",
>>     "password": "xx"
>> #        "type": "memfile",
>> #        "persist": true,
>> #        "name": "/tmp/kea-leases4.csv",
>> #        "lfc-interval": 1800
>>   },
>>
>> If I use MySQL, no lease is ever created. The server also
>> never answers any DHCP request.
>>
>> Changing from mysql to memfile (commented out code above),
>> everything works fine.
>> No error is logged, "it just dont work" with mysql.
>>
>> root@dhcp01:~# kea-dhcp4 -v
>> 1.1.0
>>
>> Debian Stretch, main repo.
>>
>> Is this a known issue?
>>
>> Kind regards,
>> Kevin
>>
>>
>> ___
>> Kea-users mailing list
>> Kea-users@lists.isc.org 
>> https://lists.isc.org/mailman/listinfo/kea-users
>> 
> 
> 
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/kea-users
> 
> 
> 
> 
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/kea-users
> 
> 
> 
> 
> 
> ___

Re: [Kea-users] option 67

[Tomek Mrugalski]

On 24/04/2018 14:48, Bob Harold wrote:
> If the client did not request it, then it probably won't understand it
> even if you send it.  If it does understand it, then it should have
> asked for it.  Or am I missing something?
In a general case yes - you are correct.

However, there are some buggy clients that don't request, but are able
to use (and sometimes even require) an option. Also, some clients have a
mechanism to transparently pass received options to a script.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] option 67

[Tomek Mrugalski]

On 24/04/2018 14:19, itay cohen wrote:
> greetings all
> 
> can i send option 67 back to the client even if its not requesting it
> (with option 55) ?
Yes. See always-send flag.

>   8.2.8. Standard DHCPv4 Options
Did you read it? The answer is in that section you cited.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Option82

[Tomek Mrugalski]

On 16/03/2018 07:19, Batuhan Bakıp wrote:
> I want to use option82 in KEA. I read KEA document but I cannot
> understand how to do. Now I use ISC DHCP and I use option82 successfully.
You posted the same question as a ticket here:
http://kea.isc.org/ticket/5575

It's much better to ask this kind of questions on a mailing list, so
thank you for doing that. Adding trac tickets that are really questions
is troublesome, because they're not meant to be used that way.

Anyway, here's the answer I originally posted to the ticket:

You specified Kea version as 1.1.0. If you are really using 1.1.0,
please upgrade to 1.3.0. There's been a lot of changes and improvements
in the client classification area.

Please take a look at section 8.2.15 here:
​https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-client-classifier.
It explains how to define a class in Kea. You definitely want to look at
Chapter 13
(​https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#classify).

You are looking at relay options. What dhcpd expressed as
agent.circuit-id is relay4.option[1].hex in Kea nomenclature and
agent.remote-id is relay4.option[2].hex etc.

If you want to restrict access to specific subnets for certain classes,
you may want to see an example in 8.6.2
(​https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-srv-example-client-class-relay).
It explains how to allow access to certain subnet only to members of
specific class (it's equivalent of allow member of "ABCD").

If you want to restrict access to specific pool, not whole subnet, this
feature will become available in upcoming 1.4. If you want to try it,
the code has been developed already and it's in our git repository.

The question you want to ask yourself is how many such expressions (each
representing a client) do you have? If you want to define many of them,
there's more efficient way to do it: You can define host reservations
(each with its own MAC address) and assign those hosts to a class.
Please take a look at Section 8.3.6
(​https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#reservation4-client-classes).

You can combine this with the class restrictions on pool and subnet level.

Finally, if you want to extract the mac addresses and ports (effectively
using MAC+port switch as client identifier), you can use flex-id to do
that. See Section 14.3.3
(​https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#flex-id).

Hope that helps.
Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Multi-tenancy in Kea

[Tomek Mrugalski]

On 07/03/2018 15:47, Jason Guy wrote:
> Hi Tomek,
> 
> Are you referring to VRF support when you say Multi-Tenancy?
No. Long time ago one company approached us asking about support for
many hotspots, each using the same overlapping address space. Kea would
see the packets coming from different relays. The company disappeared
soon afterwards and nothing came out of it.

Since Rob asked it, I though it may be a good time to do a quick
experiment. That's it. Just wanted to make it clear there's no secret
plan to develop anything in that area.

> In the latest Linux kernel (4.9+), the full VRF infrastructure is
> working well, but I don't think a lot of classic services have added
> support. It would be awesome to assign a subnet to a linux VRF.
I don't know anything about vrf, except quick look at this:
https://andir.github.io/posts/linux-ip-vrf/

If you want to have overlapping address spaces, comments from my earlier
mail apply. If you want Kea to just be able to provide addresses over
VRF interface that are globally unique, we can explore this a bit
further. How should Kea open sockets here - one for each vrf interface
(10 customers = 10 sockets)?

We already have a knob for setting outbound interface (search for
outbound-interface here
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html). There are
some improvements coming in that area soon (http://kea.isc.org/ticket/5515).

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Multi-tenancy in Kea

[Tomek Mrugalski]

Hi Rob,

I did a little experiment. With a bit of code tweaking, I managed to
force Kea to load two identical subnets that only differed in relay IP
address. It started all fine and I was able to get leases in each subnet.

There's one major caveat, though. Allocation engine, the core part of
the code that picks leases for new clients, can't tell a difference
between them and thinks the address is used, despite it being used in
the other subnet.

My subnets defined were 192.0.2.1 - 192.0.2.200. First client in the
first subnet got 192.0.2.1 (as expected), but the second client in the
second subnet got 192.0.2.2, not 192.0.2.1.

If your subnets are large (e.g. 10.0.0.0/8) you may not care. If they're
smaller, you'll use up all addresses real quick.

To implement it properly, we would have to remove getLeases4(addr) call
and implement getLeases4(addr, subnet-id) instead. There's tons of uses
of getLease4(addr) throughout the whole code (around 200 instances).
This would require a MAJOR rework of Kea code and the reworked code
would probably we worse than it is now. So am afraid it's unlikely to
happen. At least in official master. I can imagine you hacking Kea code
similar way you did dhcpd would be somewhat realistic, if you accept
that certain things will be broken.

Keep in mind that tweaking the code to allocate the leases is only the
first step on this dark and twisted path. The next step that will
probably not work is lease renewal. Then release release. After that
you'll face probably broken lease expiration. Commands related to leases
won't work etc. You can end up with all sorts of messed up situations,
like client from one network renewing a lease from another subnet, then
his lease expiring because not being renewed.

If you really want to go that path, here's a page that described my
experiment: http://kea.isc.org/wiki/KeaMultiTenant

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Problems adding the premium package hooks libraries

[Tomek Mrugalski]

specified. It's an entry similar to this:

   "control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},

As a debugging measure you may bypass the whole control agent and talk
to Kea directly over Unix socket, e.g. using socat tool:

# echo '{ "command": "list-commands" }' | socat - UNIX:/tmp/kea4-ctrl-socket

Does the response to this lists the reservation-* commands?
If not, we will continue investigating.
If yes, great!

No matter what the outcome is, I'd appreciate a lot if you let us know
how did it go.

On a related note, we need to describe the installation procedure
better. I'll make sure that is taken care of.

hope that helps,
Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] What is the relation between Kea version and PostgreSQL schema version ?

[Tomek Mrugalski]

On 02/27/18 16:26, Stéphane Klein wrote:
> Hi,
> 
> I see schema version in PostgreSQL init file:
> https://github.com/isc-projects/kea/blob/master/src/share/database/scripts/pgsql/dhcpdb_create.pgsql
> 
> schema version 1.0, 2.0, 3.0 and 4.0.
> 
> What is the relation between Kea version and schema version ?
It's just a version used to determine whether the DB should be upgraded
or not during upgrading to new Kea version. Sometimes there are no
changes in the schema, even though Kea version has changed. For example
Kea 1.2 used Postgres schema 3.1 and so did Kea 1.3, because in the
meantime nothing was changed in the schema.

Each backend has its own schema version number. We bump up major version
when there are backward incompatible changes. We bump minor versions
when there are smaller changes that are generally backward compatible.

Details in Section 4.1:
http://kea.isc.org/docs/kea-guide.html#kea-database-version

> Schema version 3.0 for Kea 1.3 ?
3.1 for Postgres, 5.1 for MySQL and 1.0 for Cassandra.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] How to insert properly hosts in Kea PostgreSQL database?

[Tomek Mrugalski]

On 02/27/18 15:38, Stéphane Klein wrote:
> Do you have example how to insert properly my host in Kea PostgreSQL
> database?
Have you read this http://kea.isc.org/wiki/HostReservationsHowTo?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] SQL host reservations (Kea 1.3.0)

[Tomek Mrugalski]

On 01/17/18 17:44, Tobias - wrote:
> Great! How could I have missed that? That's exactly what I've been
> looking for. I just didn't dig deep enough I guess.
We should probably make this page a part of the user's guide. Would that
be easier to spot?

Also, there will be similar wiki page (or user's guide section) about
Cassandra. Cassandra does things slightly differently. The docs about
that are not written yet, but they will be for 1.4-beta.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Subnet Addresses via Kea API?

[Tomek Mrugalski]

W dniu 03.01.2018 o 20:16, Duane Wylie pisze:
> I'm attempting to put together a process that would report DHCP pool
> utilization.  Per-subnet numbers are easy via the API:
> 
> 
> "command": "statistic-get-all"
> 
> 
> I get data in this format:
> 
> ...
> 
> "subnet[152].total-addresses": [ [ 13, "2017-12-27 10:38:52.086719"
> ] ] }
> 
> ...
> 
> 
> But what I'm not finding is a way to derive the actual network
> information for the subnet (What is the network address? subnet mask?
> etc...)
Kea 1.3.0 now supports subnet4-list and subnet6-list commands. See
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#subnet-cmds

These commands are part of the subscription package.

> For my deployment, the intention is to manually number all subnets in my
> kea-dhcp4.conf file, but in a broader sense it is legitimate to not do
> so, and have Kea number them automatically on startup.  In the automatic
> ID assignment scenario, how could I programmatically discover the
> ID-to-subnet assignments?
This is what the call returns:

{
"result": 0,
"text": "2 IPv4 subnets found",
"arguments": {
"subnets": [
{
"id": 10,
"subnet": "10.0.0.0/8"
},
{
"id": 100,
"subnet": "192.0.2.0/24"
}
]
}

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Weird stats from a shared database

[Tomek Mrugalski]

W dniu 12.12.2017 o 15:48, Munroe Sollog pisze:
> Let me know if this should be a bug, but I have noticed some weird stats
> when running two kea-1.3 DHCP servers from the same mysql database
> (using Galera).
> 
> I have included a screen grab of the stats.
> 
> Between noon and 2pm yesterday we when I migrated rogi from the memfile
> to the mysql database.  I migrated all of the existing leases from the
> CSV to mysql and started rogi.
> 
> Igor from around 2:30pm until about 7:45am the next day it steadily
> declines all the way to -436 leases.  How can it possibly have
> *negative* leases?
Rasmus is right. Running more than one Kea server using the same
database is not officially supported.

Here's what is likely to happen: each Kea instance allocates leases to
clients. For each allocation, the statistic is increased. The statistic
is observed on each instance. It is likely to be incorrect as there is
another instance that also allocates leases.

Now, unless you took extra steps to disable lease expiration on one
instance and keep it running on another, there are two instances
periodically looking for leases that are expired. Depending on how many
leases are expired during exact moment when the expiration triggers, one
server may get more expired leases to process than the other. Only that
server will decrease the statistic.

Finally, I don't know how you set this up, but I presume that the server
that allocated a lease will send its own server-id and thus the release
messages will be processed only by that server. So this shouldn't
contribute to the confusion, unless you did some clever things with
server-id.

You may perceive it as a bug. It's a valid point of view. But I see it
as Kea being run in a configuration that is not officially supported.
There's nothing wrong with it. We're happy it provides service and
generally works. It's just there are quirks like this.

We do have recountLeaseStats4 and recountLeaseStats6 method, but it is
only used internally. I suppose we could expose it as a command that you
could call. Kea instance would then consult the database and recalculate
the values.

As Rasmus mentioned, we do plan to improve the situation significantly
in 1.4. We want to provide a high availability solution, but also
improve many aspects of running multiple Kea servers at the same time.

I don't have any specific solution for you right now, just some things
to consider. Kea doesn't have any notion (at least not yet) of a server
instance owning a lease. You could try generating the statistic by
pooling both servers and adding the values together. Consider it an
experiment. It may or may not work. I'd love to hear about the results.

I'd like to ask you a favour. Can you describe how you did set up Galera
for MySQL on kea wiki? There are installation instructions here:
http://kea.isc.org/wiki/Install I was thinking about something similar,
but with detailed instructions how to set up Galera cluster. This would
be useful for two reasons. First, other users could set it up in similar
fashion. Second, one of ISC engineers will get to look at this problem
one day. It will be very helpful to have an instruction to replicate
your environment.

Finally, can you submit a bug for this? It would great if this bug
report had a link to the installation instruction.

Hope that helps,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] How is tsid generated

[Tomek Mrugalski]

W dniu 11.12.2017 o 22:38, Munroe Sollog pisze:
> Can someone help me understand how the tsid field is generated?  What is
> used to generate that hash?  I’m tracking DHCP performance based on the
> tsid and I’m seeing a very small percentage of long transaction time
> that may be explained by colliding tsids. 
Are you asking about transaction-id, a 32 (in DHCPv4) or 24 (in DHCPv6)
bit field in the DHCP message or tsig, a signature used to protect DNS
updates? You mentioned a hash, which suggests the latter. Anyway, here
are brief answers to both.

xid, or transaction-id, is not a hash. It is supposed to be set by a
client to a random value, but some clients set it a special value. Kea
doesn't pay much attention to it, except it being echoed back in its
responses. This value is used by clients to match responses to their
outstanding transmissions. For details, see RFC2131, Section 2, page 10.

tsig, or transaction signature is used to sign DNS updates. Kea supports
a number of algorithms (hmac-md5, hmac-sha1 and others, see Section
11.3.2 for details:
http://kea.isc.org/docs/kea-guide.html#d2-tsig-key-list-config). This
mechanism is defined in RFC2845. I haven't looked at the details, but I
presume it protects the whole content of the DNS message, so everything
in the DNS update message, a timestamp and a secret key are used to
generate that digest.

Hope that helps.
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] limiting how many leases someone can get

[Tomek Mrugalski]

On 16/11/2017 04:19, John Ratliff wrote:
> I would like to replace ISC DHCP with kea. Currently, we're using
> classes to put a lease limit of 1 on each household. The class is
> created based on remote-id or circuit-id (option 82 information).
> 
> Is it possible to do something similar with kea? I see that you can do a
> lease reservation based on circuit-id, but I didn't see anything about
> lease restrictions. It seems like the limits are based on MAC alone.
Explicit lease limits are not supported yet.

Some capabilities for limiting number of leases are being under
consideration and they may appear in 1.4, but that depends on business
aspects that are completely outside of our control.

Having said that, you may get a similar functionality under certain
conditions. If you have a list of remote-id or circuit-ids for your
clients, then just define reservations for them, define a subnet and
don't define any pools. This way the clients having a matching
circuit-id or remote-id will get an address. Just one. Those that don't
match your reservations won't get any address at all.

I admit this approach is somewhat limited. If the device behind specific
remote-id or circuit-id changes, then Kea will detect a conflict and
will try to resolve it, but then will likely fail to pick an alternate
lease, because there is no dynamic pool. Once the old lease expires, the
new device will be able to get a lease for the same address.

If you don't like that approach, you can try using replace-client-id
parameter set to true in flex-id hook. This should cause the old lease
to be stored with client-id matching your remote-id or circuit-id. When
a new device is connected behind the same location, its generated
client-id will match the old one, so Kea will look at this as if the
device changed mac address, but has the same client-id and will issue
the same address to the new device. I have not tested this, though. I'm
currently on a conference and don't have access to my home test setup.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] subnet scope DHCPv4 options in database?

[Tomek Mrugalski]

W dniu 10.11.2017 o 16:27, Owen Dunn pisze:
> However, it seems that subnet-scope options in the dhcp4_options table
> are not processed.
Not supported yet. This is currently planned for 1.5.

Currently (1.3) you can store options associated with host reservations.

> I have my subnet (with id 29) defined in the config file, and kea is
> able to give my client the correct reserved address.  However, the
> options for that subnet in my dhcp4_options table are not passed on. 
> What am I doing wrong?
Nothing. Is there any part of the User's guide that suggested this is
supported? If there is, please point it out and we'll make the docs more
clear.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Subclass and include files

[Tomek Mrugalski]

On 17/10/2017 19:58, Sten Carlsen wrote:
I use subclass for keeping a list of devices that are allowed to be 
given an address and depending on the class they match, they will be 
given a gateway or not (I want some devices to NOT be able to 
communicate to the Internet). Devices that do not belong to any class 
are given an address in a different subnet with no routing to the 
general network.
You should look at host reservations. You can define host reservations 
that consist of a mac address and a class name. Kea will pick the 
reservation and then assign the device to a class (or classes).


You can then specify a class and routers option for it. Just don't 
specify any expression for it. The only way for a client to be assigned 
to that class would be through matching host reservation.


I don't find an equivalent to this in Kea, so how would be the best way 
to translate my subclass statements to "something" in Kea?
There's no specific equivalent of subclasses. Years ago I was told that 
subsclasses were developed as a workaround for the class limitations. 
Kea's implementation of classes is in principle more flexible (e.g. 
there are no limits to how many classes a packet could belong), so it's 
unlikely that subclasses would ever be implemented.


Today I use a separate file for defining all the subclass members and 
include that in the main configuration file, so I only edit that file 
when a new device is added. Can a file be included into the main 
configuration in Kea?
Sure, you can do that. Put host reservations in separate file and 
include it, as Jason suggested.


At some day in the future I expect to use a MySql database as the main 
storage, but not right now. The future also brings ipV6 configuration.
This will scale up nicely once you start using MySQL (or Postgres) as 
you can keep host reservations in those DBs.


Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] timers defined on gloval scope are not exported with the get-config command

[Tomek Mrugalski]

W dniu 04.10.2017 o 17:05, itay cohen pisze:
> the global timers would be returned as you defined them <-- that would
> be grate.
Cool.

> the subnets that had those global timers applied, would return their
> values as well. Would that be ok? <-- maybe add an indication to know
> that is from global and not local This would be difficult to do. When we 
> parse the original configuration
and the timer values are calculated, we don't retain the information
where they came from. To store that additional value would be a
significant effort and would complicate the code a lot, so am afraid
we're not going to do it, because the benefit is far too small for the
required amount of work here.

If you want to go into more details, we have a code that once the JSON
structures are loaded, we go through them and fill in the blanks. We
first start with default values. For example, if a user didn't specify a
value for valid-lifetime, we fill it with the default. Next, we go
through the structures and derive or inherit values that are not
explicitly set. At that stage, every subnet has all timers and other
parameters defined and it is ready to be applied.

This approach simplifies the actual parser significantly, because it
doesn't have to deal with the optional parameters. Almost everything is
always specified. This makes the code much simpler, easier to maintain
and extend. The price for this approach is that we lose the information
where exactly the value came from.

Hope that explanation is ok for you.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] timers defined on gloval scope are not exported with the get-config command

[Tomek Mrugalski]

W dniu 04.10.2017 o 06:25, itay cohen pisze:
> my concern is that some parameters are configured in the config file,
> and when i'm pulling the configuration via api the parameters are not there,
The short answer to this is: can you submit a bug report for this on
kea.isc.org?

The slightly longer answer is that we use the values while parsing the
configuration to derive values in subnets, but afterwards do not store
the global values. The config returned has the values applied to subnets
that did't have the values specified.

We can extend the configuration handling code to keep the global values.
This is easy to do. What we can't fix is the values returned by subnets
that did have the global values applied to.

So, the global timers would be returned as you defined them, but the
subnets that had those global timers applied, would return their values
as well. Would that be ok?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] subnet_id - what values can you use?

[Tomek Mrugalski]

W dniu 13.09.2017 o 17:59, Neil Briscoe pisze:
> What values can I put in there?  I have tried integers from 1000-64000,
> but still complains.
A full range of unsigned 32 bits integer in principle should work, but I
would avoid the extreme values: 0 and 4294967295. Everything else in
between should work.

As others pointed out, integers are written without double quotes, which
are used for expressing strings. subnet-id is an integer.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Dynamic options generation.

[Tomek Mrugalski]

W dniu 06.09.2017 o 16:50, Francis Dupont pisze:
> Marcin Jurczuk writes:
>> I'm evaluating isc-dhcp replacement with kea and I've stumbled upon some conf
>> iguration options that I don't know how to convert to kea format.
> 
> => we have a tool doing this (it works well even there are some deep
> differences between ISC DHCP and Kea). Note if the option is standard
> for ISC DHCP (defined in common/tables.c) we have 2 tickets which
> implement it in Kea (if it is not yet supported).
The point of the question was to have the options generated dynamically.
And sadly that's not something you could do without a bit of programming.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Dynamic options generation.

[Tomek Mrugalski]

W dniu 06.09.2017 o 15:29, Marcin Jurczuk pisze:
> Hi,
> 
> I'm evaluating isc-dhcp replacement with kea and I've stumbled upon some 
> configuration options that I don't know how to convert to kea format.
> Many options in my ISC dhcp are generated "on the fly" from data retrieved 
> from DHCP DISCOVER packets.
> For example:
> --
> filename = ucase(concat(DEVICE_MODEL,"/",remote-id));
> --
> Where remote-id is device Mac address after some formatting and DEVICE_MODEL 
> is value from one of fields from option-43
> In effect devices is getting string like "MOTO234/001122AABBCC"
> 
> Is there a way to get same result it kea without writing hook library code ?
Sadly, no. Writing hook code is the only way for now. But it's something
that should be implemented. Can you submit a ticket for it on kea.isc.org?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Building Kea with C++11 compiler in Centos6

[Tomek Mrugalski]

W dniu 31.08.2017 o 20:15, Gokulakrishnan Gopalakrishnan pisze:
> I'm building Kea in Centos6 box, where C++11 compiler doesn't come as
> default with OS. So, I installed devtoolset as mentioned
> in https://hiltmon.com/blog/2015/08/09/c-plus-plus-11-on-centos-6-dot-6/
> 
> As per the blog, after installing devtoolset we have to enable C++11
> compiler by using scl enable devtoolset-2 bash command. Then
> './configure, make, make install' for Kea would work.
> 
> In my local Centos 6 box, this works well. But in my build
> machine scl enable devtoolset-2 bash  command doesn't work due to some
> limitations. Anyways, devtoolset is installed.
> 
> Is there any other way to specify C++11 compiler to build Kea?
Yes, there is. You can set CXX variable. For example:

CXX=g++-6 ./configure

If you need any extra flags, you can set CXXFLAGS the same way.

There's a wiki page describing Kea installation on various systems. We
do have one for CentOS 7, but not for 6. Would you be willing to write one?

Thanks,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Side-loading pool configuration information from a database

[Tomek Mrugalski]

W dniu 30.08.2017 o 09:33, Daniel Corbe pisze:
> I want to stick my pool configuration in the database.  I don't want to
> maintain it in the config file.
> 
> Is it possible today to do this?
Not yet. The capability to store subnets (and pools) in a databases is
likely to be implemented in 1.5.

> If not, can it be implemented with hooks?
It could be, but depending on how you deploy your configuration it may
be a bit tricky to implement. We do have control_command_receive hook
that processes incoming commands. One of such commands is config-set. If
you deploy your configuration using that, rather than reading everything
from a file, you could write a hook that would get in action when
config-set command is received and ignore any other commands. Such a
hook could get the subnets and pools, convert them to JSON (or more
precisely Element structures), inject them into the arguments of
config-set and then pass it back to Kea for normal parsing.

If you're reading the configuration from a plain file, there's no easy
way to handle it. The problem is that in principle having a hook being
fired off when configuration is ready sounds like a good idea, but the
problem is how would you hook a library onto it if the configuration
that describes which library to load is being loaded? We could add a
hook configuration_changed that's called afterwards, but then you
wouldn't benefit from all the sanity checks that Kea is doing on the
configuration.

If you really want to, you can write a library that's being loaded, does
not install any callouts, but instead modifies the server configuration
from within its load() function. Not 100% sure, but that should work.
Just need to do some experiments whether you need to modify staging or
current config (see CfgMgr::getStagingCfg() and
CfgMgr::getCurrentCfg()). Should work, but that's more of a hack rather
than a clean solution.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] New Kea hook to call external scripts: kea-hook-runscript

[Tomek Mrugalski]

W dniu 24.08.2017 o 12:21, Baptiste Jonglez pisze:
> I have developed a generic hook that calls an external script at all hook
> points provided by Kea.  The goal is to simplify integration with Kea: for
> many simple use-cases, it is overkill to have to write a full-blown Kea
> hook, where a simple shell script can do the job.
> 
> This could be useful for several use-cases, but we currently use it to
> add/remove routes in the kernel routing table when DHCP clients connect or
> disconnect.
> 
> The code and documentation are here:
> 
>   https://code.ffdn.org/zorun/kea-hook-runscript
>   https://github.com/zorun/kea-hook-runscript (mirror)
I always thought about writing this kind of hook, but never had time for
that and hoped someone would write it one day. And here you are. Great!

Thanks for writing it and sharing. I have not tested it yet, but the
code looks good at first glance.

One thing you should consider in the future is that if the script takes
a long time to execute, it will freeze whole Kea execution. You may add
a knob that lets the user pick - whether he wants to wait for the script
completion or not.

Thanks again,
Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] [kea-dev] Raw socket input buffer

[Tomek Mrugalski]

W dniu 31.07.2017 o 12:36, Francis Dupont pisze:
> k...@jack.fr.eu.org writes:
>> I have a kea4 server, version 1.1.0, I added hooks that connect
>> externally (the important information : that hook is "slow", it does TCP
>> connect)
>> That part works well
>>
>> However, when the server takes too many queries (I don't know how "too
>> many" is), a strange behavior appears: the server keep and answer
>> outdated requests (some kind of input buffer, I guess), which clients
>> timed-out in the mean time, leading to another requests etc -> broadcast
>> storm and global failure
> 
> => as your tentative fix suggested this is a kernel issue: pending
> queries are simply queued waiting Kea to read them. IMHO the best is
> to add some code in the slow hook to flush them.
> 
>> I tried to reduce /proc/sys/net/core/rmem_max to 4096, this does not fix
>> the issue (probably because 4096 is still a lot of dhcp-packets :p)
According to man 7 socket, the minimum value you can set there is 256.
This is a doubled value (see the man page for explanation), which in
principle could allow you to buffer up to 128 bytes. This is definitely
in range of a single DHCP packet. Obviously, nobody recommends setting
it to such a low value. But if you want to drop packets while previous
packet is being processed, this is one thing to possibly try.

>> Any tip, trick, configuration or whatever on that issue ?
> 
> => slow processing is incompatible with the DHCP protocol so basically
> there is no final fix, only tricks to make things less broken.
Yes. One day we will have to extend the hooks mechanism to make it
asynchronous. This is still a bit far away, because this most likely
means Kea will need to be multi-threaded or at least multi-process. Both
are non-trivial.

But before we fully embrace that, we could look whether there's a way to
get the timestamp from kernel regarding when the packet was received. If
there's a way to do that, we could reject packets that spent too much
time in a buffer and are now stale. This shouldn't be super complex to
implement, but sadly our schedule for upcoming 1.3 is pretty tight.

But as Francis said, this would be another trick. The ultimate solution
would be to implement async hooks.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] using sql expression in client classification

[Tomek Mrugalski]

On 18/07/17 13:57, Francis Dupont wrote:
> => use client classification is usually the best way, now Kea classification
> relies only on the query packet so if another parameter is needed
> a hook is required (note it is a common case so there are already
> some examples. Unfortunately the idea to join a contributed hook library
> with Kea sources is still only an idea).
The problem with accepting a hook code as contribution means that ISC
would have to spread its very limited engineering resources. So yes,
it's not out of question to accept such a patch, but in the mean time
we're maintaining a list of hooks that are available:

http://kea.isc.org/wiki/Hooks

If you are developed your own hooks, feel free to update the list.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] user_chk not installed

[Tomek Mrugalski]

W dniu 28.06.2017 o 12:43, Thomas Markwalder pisze:
> We deliberately do not install this library as it is primarily an
> example hook library intended as a learning tool and not likely to be
> something admins want in a production  installation.
Perhaps it's useful to explain why we made this decision. user_chk is an
example library that showcases how one could use hooks interface. It was
written with simplicity and clarity in mind, not performance.

In particular, every time a new packet comes in, the library re-reads
and parses the known users file. This is nice when you want to
demonstrate how hooks are working, but it's rather poor from performance
perspective. The more packets per second you get and more entries you
have in a file, the worse performance you'll get.

If this library were installed by default, the difference between
educational example and production ready library could be lost and
people would complain that Kea performs poorly.

Regards,
Tomek Mrugalski
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Forcing a DHCP realease in Kea.

[Tomek Mrugalski]

W dniu 05.06.2017 o 14:03, Joelson Vendramin pisze:
> Hello all,
> 
> Is there a way to force a DHCP_release from the command line in Kea?
There isn't one in Kea 1.2, but there will be in 1.3. They will be
called lease{4,6}-del. See here: http://kea.isc.org/wiki/Commands for a
high level overview.

> I'm trying to implement an external mechanism (bash script) that
> monitors the "gone-away" clients and than releases immediatelly its IP
> (v4 & v6) addresses. I'm afraid that if my script write directly into
> the leases CSV file (I'm using memfiles), it would bring unexpected
> results to Kea while it's running.
Writing to the lease file from external sources while Kea is running is
just asking for troubles. You can tweak (and in particular delete a
lease) a MySQL or PostgreSQL DB while Kea is running.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Migrating from ISC DHCP

[Tomek Mrugalski]

(you mentioned customer CPE identification, so I presume you have). One
limitation is that currently client classes are global.

You can specify client-class on per subnet basis, but that is used for a
different purpose. It prevents clients that do not belong to a class
from even using a subnet. It's useful to remember the order in which Kea
does its operation:

1. packet is being classified (global client-classes are applied)
2. subnet selection is conducted (classes assigned in step 1 may affect
this step)
3. lease is selected from the subnet. If a client has a reservation in
this subnet, it is being used. If that reservation contains
client-classes, the packet is being assigned to that class.
4. options being added, possibly based on the class information.

Hope that helps,
Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Bind service to loopback address

[Tomek Mrugalski]

W dniu 19.04.2017 o 16:35, Jason Guy pisze:
> I would like to leverage my routing on the host setup, and bind the kea
> service to the loopback address I have configured. This would ultimately
> allow me to deploy multiple kea servers with an "anycast" reachability.
> 
> ip addr show lo
> ...
> inet 10.50.5.11/32  brd 10.50.5.11 scope
> global lo:1
> ...
> 
> Kea.conf:
> ...
> "interfaces-config": {
> "interfaces": [
> "lo/10.50.5.11 ",
> "eth0",
> "eth1"
> ]
> },
> 
> 
> I have tried specifying this in a few ways, and the DHCP relay packets
> reach the server, but Kea does not appear to process them. I thought
> about putting the loopback on the ethernet interfaces as secondary
> addresses, but wanted to understand why I can see the relay packets
> arrive but not picked up by Kea.
Kea uses raw sockets by default to receive DHCPv4 traffic. Raw sockets
receive raw packets, i.e. everything that comes over wire (ethernet
header, ip, udp and everything that follows). This is different on
loopback as there's no notion of ethernet headers there. Kea has some
support for loopback traffic handling, but it's not used extensively, so
did not receive much testing.

Have you tried setting dhcp-socket-type to udp? If that doesn't help at
all, can you open a ticket for this?

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Kea DHCP anf FreeRADIUS

[Tomek Mrugalski]

W dniu 18.04.2017 o 17:35, Marcin pisze:
> Hello,
> Question to developers. Are there any plans to add FreeRADIUS as
> authenticator and accounter server?
Not at this time. It could be done with hooks. It would require a fair
bit of coding.

IIRC this is the first time a radius integration was requested for Kea,
so I presume this functionality wouldn't be super popular among users.
Based on that I would say adding it to the roadmap is rather unlikely.

Of course that could change unexpectedly. Someone desperately needing it
could come up with money and sponsor its development. This happened
before. It's also possible that a paying customer would send up a
feature request for RADIUS support to be added.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] DHCPv6 allocations (IA_NA and IA_PD) based on interface-id (relay Option 18) [update: solution provided]

[Tomek Mrugalski]

W dniu 31.03.2017 o 19:21, Joelson Vendramin pisze:
> Just to update you that I found a (possible) solution for the
> configuration I posted yesterday. Maybe it's not the "best" or most
> "elegant" solution, but it worked as I expected. Basically I'm using
> "/128 IPv6 subnets" and the "interface-id" parameter to read option
> 18 inserted by relay.
> 
> The DHCPv6 piece of kea.conf is in the sequence.
Thanks for sharing. Yes, this should work. However, there will be a
performance degradation if you scale this up to many thousands or more.

I'm working on a solution to this problem. It's called Flexible
identifier. With this approach, you can define an expression, e.g.
"relay6[*].option[18].hex" which will take option 18 (interface
identifier) from the relay encapsulation and will use its content as
value. That value could then be used for host reservation selection.

So you could do the following:

// First you defined what your flexible identifier is.
// This is done only once in your config.
"identifier-expression": "relay6[*].option[18].hex",


// and then for each of your devices, you'd add a host reservation
// entry simialr to the following
"reservations": [
{
"flex-id": "'routername eth 0/6:333'",
"ip-addresses": [ "2001:db8:bd00::119:2" ],
"prefixes": [ "2001:db8:bd01::/48" ]
},
// more reservations here
]

This should perform better and probably is easier to manage.

In the next couple days it will also be possible to store this
information in MySQL and/or PostgreSQL, so it would scale well even if
you had millions of entries.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] problem in custom option

[Tomek Mrugalski]

On 30/03/17 10:42, Francis Dupont wrote:
> Known and fixed defect:
> 
> 1213.   [bug]   fdupont
> Option string values containing comma can now be specified
> correctly by preceding comma with double backslashes (e.g.
> "foo\\,bar").
> (Trac #5105, git fa79ac2396aa94d7bac91bd12d3593ebaaa9386d)
This code will be released in upcoming Kea 1.2 beta, scheduled for early
April. If you can't wait for it, the unreleased code is already
available on github.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Saving additional information on the lease info

[Tomek Mrugalski]

On 27/03/17 08:27, Egi K wrote:
> What I would like to achieve is storing also the interface-ID on the
> lease entries when i am using prefix delegations. Because i can see the
> lease information for the end client, but i cant find out a way to
> relate this end-client to the device which is currently doing the prefix
> delegation.
There is no way to do it out of the box. Depending on what you need this
information for, there are couple options. First, if you need it for
legal or audit purposes, you may be interested in Forensic logging
library. It stores extra information, including interface-id in
dedicated audit log files.

If you want to store the information in the DB, probably the easiest way
would be to write a hook for pkt6_send. You could extract the lease
information from the response6 packet and the value of interface-id from
query6. At that stage the lease is already in the DB, so you could do:

 UPDATE lease6 SET extra_info=... WHERE address=...

This is not the optimal solution from the performance perspective (you'd
have 2 queries for each lease addition/update/delete), but it's probably
the easiest to implement.

> Is there any possibility to store this additional info?
Not with the current code.

You can consider those two options above. If neither of them work for
you, we can talk about other options. The key question is how badly do
you need this feature?

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] from dhcpd to kea; classes and subclasses

[Tomek Mrugalski]

W dniu 23.02.2017 o 13:58, Philippe Maechler pisze:
>
> Hello Kea-Users
>
>  
>
> We’re running two pairs of dhcpd in our cable and fibre network. The
> setup or the config file gets more and more complex and hard to debug
> or make new stuff.
>
> Since we want to use reserved leases and often have to end a lease
> before it expires, we’re thinking about using kea.
>
> The last time I looked at kea was before class support was available,
> which we also heavily rely on. Meanwhile kea supports classes and I
> think it’s worth a try ;)
>
>  
>
> A few questions arise before I try to merge our current configuration:
>
> 1. For our fiber network we have a group with global options.
> Inside the group we have several hosts
>
> e.g:
>
> group {
>
>option vendor-encapsulated-options = "s=;v=";
>
> host CATV_01_ONT{hardware ethernet 0:11:22:33:44:10;}
>
> host CATV_02_ONT{hardware ethernet 0:11:22:33:44:20;}
>
> host CATV_03_ONT{hardware ethernet 0:11:22:33:44:30;}
>
> …
>
> }
>
> Are groups supported in kea? In dhcpd we’re using a class for each
> option-82 and provide global options inside a group.
>
No, but you can get similar functionality with classes. You can define a
class with option values and then assign host reservations to specific
class.
>
>  
>
> 2. Each customer (or each option-82) gets one (1) IPv4 address, an
> IPv6 address an an IPv6-Prefix/56. There are a few cases when a
> customer gets 2, 3 or sometimes 4 addresses. We solved this with
> dynamic subclasses
>
> // native vlan, only used when the cpe boots
>
> class "CATV_01_Port" {
>
> match if ( substring ( option agent.circuit-id, 0, 25 )  =
> "gaswXXX003 eth /" );
>
> match hardware;
>
> }
>
> // voice vlan, only if the customer has voice
>
> class "CATV_01_Voice" {
>
> match if ( substring ( option agent.circuit-id, 0, 30 )=
> "gaswXXX003 eth /:" );
>
> spawn with option agent.circuit-id;
>
> lease limit 2;
>
> }
>
> // data / HSI vlan
>
> class "CATV_01_CPE_DHCP"   {
>
> match if ( substring ( option agent.circuit-id, 0, 30 )   =
> "gaswXXX003 eth /: " " );
>
> *spawn with option agent.circuit-id; *
>
> *lease limit 1;*
>
> }
>
> I haven’t seen anything regarding subclasses in the kea admin guide.
> Is this setup possible or are there any other methods to achive this?
>
Long time ago Shawn Routhier explained that sub-classes were implemented
in dhcpd as performance optimization thing. There is not and there
likely won't be support for sub-classes in Kea.

What does the XXX stand in each class above? Are they the same or
different for each subclasses? If they're different, you can define
three separate reservations for it. Not sure if I read it correctly, but
subclass 2 and 3 have the same first 30 bytes of the circuit-id. Is that
correct?

>  
>
> 3. Are static addresses based on the option-82 and not the mac
> address available in kea?
>
> e.g
>
> host ABCD {
>
> option agent.circuit-id = “gaswXXX003 eth /:”;
>
> ipaddress = 10.1.2.3;
>
> }
>
> /I didn’t check the syntax of that/
>
You can have the reservation in v4 based on one of the following:
hw-address (that's hardware address set by the client in its packet),
duid (some clients can put their DUID within client-id), client-id
(that's an option inserted by a client) and circuit-id (that's the
agent.circuit-id option). That's described here:
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#host-reservation-v4

For v6 we support reservations by duid and hw-address. However, you can
specify where the hw-address should come from and we currently support
duid, ipv6-link-local (both are set by the client) and several options
inserted by relays: client-link-addr-option, remote-id, subscriber-id,
docsis-cmts, docsis-modem.

General description of v6 reservations:
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#host-reservation-v6

Description how to make Kea treat various options as MAC addresses.
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Multiple ipv6 addresses/prefix reservations

[Tomek Mrugalski]

W dniu 23.02.2017 o 11:35, Olivier Clavel pisze:
> On http://kea.isc.org/wiki/KeaKnownIssues I see that  /"/Static
> reservation of multiple IPv6 addresses or multiple IPv6 prefixes is not
> supported." was specified for versions up to 1.0.0 but as been removed
> on 1.1.0. Does that mean I can reserve several IPv6 addresses on
> different network/pools for a single client ? Anything special to deal
> with in the configuration ?
Having a reservation for the same host in different subnets worked for a
long time, for both v4 and v6. That's the case when client moves to a
different location in your network.

Now, DHCPv6 allows for a client to get more than one address and/or
prefix and given location. To support that, the client should send more
than one IA_NA (for address) and/or IA_PD (for prefix). Kea supports
that for a long time.

What has recently been improved is the ability to reserve multiple
addresses or prefixes at one location. To take advantage of that, your
client needs to send multiple IA_NA and/or IA_PD.

I just noticed that there's a small bug in the documentation. Section
8.3 incorrectly states how to reserve multiples addresses:

INCORRECT TEXT:
{
   "hw-address": "00:01:02:03:04:05",
   "ip-addresses": [ "2001:db8:1::101, 2001:db8:1::102" ]
},

SHOULD BE:
{
   "hw-address": "00:01:02:03:04:05",
   "ip-addresses": [ "2001:db8:1::101", "2001:db8:1::102" ]
},

I just pushed this correction to master. The user's guide is being
regenerated daily, so this link should be correct tomorrow:
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#host-reservation-v6

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] dhcpsrv folder missing in include dir

[Tomek Mrugalski]

W dniu 23.02.2017 o 12:47, Rui Pedro Caldeira pisze:
> Hello guys, I come for assistance once again. I'm building kea 1.1.0 and
> after the build process I'm missing the dhcpsrv folder inside the
> include dir. Without that I cannot link with the lease4_select hook to
> get the Lease4Ptr object. Any help?
The headers should be installed, but they aren't. That's a bug in Kea
makefiles. Please submit a ticket at kea.isc.org.

As a workaround, you can copy the header files manually (or include kea
source directory in your build).

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] leasequery and PD reservations

[Tomek Mrugalski]

W dniu 15.02.2017 o 15:37, Torbjörn Eklöv pisze:
> Thanks. I get remote-id and client-id in the log now but there are more 
> issues that prevents me from using it in production.
> I miss this now:
Ahhh, new requirements.

> - leasequery
We don't have this planned. It's not a frequently requested feature by
any means. It's unlikely leasequery would be implemented in a near
future, unless there are people who are willing to step up and fund its
development.

Also, there are now 3 types of leasequery protocols defined right now. I
presume you're talking about the "basic" one, right?

For completeness, here are the RFCs that define them:

1. RFC5007 - DHCPv6 Leasequery (requestor asks about specific address or
about specific identifier and gets one reply, works over UDP)

2. RFC5460 - DHCPv6 Bulk Leasequery (requestor can get many responses,
e.g. give me all clients that connected through relay X, works over TCP)

3. RFC7653 - DHCPv6 Active Leasequery (requestor subscribes to the
server, and then the server sends any lease updates as soon as they
happen, works over TCP or TLS)

> - lease database where I assign PD prefix depended on client-id and remote-id
I recall similar request was discussed previously, but I reviewed my
mail archive and can't find it. Anyway, here it is:

Reservations are stored in a separate table, so they're not exactly the
same as "lease database". Those can be kept in MySQL, PostgreSQL or in
the config file. (There's also an unreviewed patch for Cassandra, but I
would recommend against doing anything with it in production).

For any given client, do you need both client-id and remote-id? If yes,
that's not supported. If you can do a reservation by client-id OR
remote-id, there is something you can try. PD can be reserved for
client-id (use "duid" keyword). PD can also be reserved for specific
hardware address (use "hw-address" keyword) and configure your MAC
source to use treat content of remote-id as MAC.
See Section 8.3
(https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#host-reservation-v6)
and Section 8.9
(https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6).

Implementing more reservation types is one of the strong candidate
features for upcoming 1.3. However, the decision hasn't been made yet.
Mid to late March sees to be the timeframe to scope features for 1.3.

> Does anyone on this list know a product that can do what I want? ISC DHCP and 
> Dibbler don’t
Forget about Dibbler. It was a hobby project I did over weekends, but it
isn't maintained. I did that for 13 years, but I simply don't have time
for that any more.

Depending if the hw-address+mac-sources trick works for you, you may be
missing leasequery only. Or perhaps leasequery and the reservation stuff
if the trick doesn't cover your case. One of the things we consider for
1.3 is a generic reservation mechanism. You'd define an expression in a
way similar to client classification and use values of that expression
in your reservations.

It seems the biggest problem here is leasequery. So how badly do you
need it?

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea-dhcp6 option 18 and 37 logging

[Tomek Mrugalski]

W dniu 01.02.2017 o 09:49, Torbjörn Eklöv pisze:
> I have tested to set debug level to 45 and up to 65 on ”*” ,
> ”kea-dhcp6” and ”kea-dhcp6.packets” but I can’t see the remote-id in
> the log. In a tcpdump I can see both option 18 and 37 but I can’t see
> them in the log.
That issue (http://kea.isc.org/ticket/5131) is now fixed. When used
debuglevel 45 or greater, Kea will now log all the relay options. That
includes remote-id, interface-id and whatever else the relay may have
sent. Note that there may be a lot of data. This change is available on
github.

We have also updated our forensic logging library. Here's the ChangeLog
entry for it:

  Forensic logs library now prints remote-id and subscriber-id
  values from the DHCPv6 relay closest to the client. Interface-id
  from DHCPv6 relay is now printed, if present. Subscriber-id added
  by DHCPv4 relay is now printed, if present.

This change is available for subscribers only.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] IP address conflict handling

[Tomek Mrugalski]

W dniu 09.02.2017 o 00:07, Klaus Steden pisze:
> Thanks! That was a terrific explanation. Where does Kea store the record
> for the "hijacked" address? Does it live in the existing lease table, or
> somewhere else (we're using MySQL as the backend, so I don't know if it
> will be visible in the DB, or if it gets stored locally in another
> lease-file-like file.)
yes, it's just reassigned to a special fake DUID or hardware address and
stored with other currently assigned leases. It then undergoes similar
procedure as a normal leases which are expired after their lifetime
elapses. For declined leases, it's called probation period, but
technically it's the same timer for both cases. Kea processes them
mostly in the same way (there are minor differences, like for declined
lease being recovered there are extra statistics that needs to be adjusted).

I don't remember off-hand the syntax of the special DUID/hw address, but
I think it was something like 1 byte long expression. It should
definitely stand out in the lease file or in your DB.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Select subnet based on reservation?

[Tomek Mrugalski]

W dniu 08.02.2017 o 16:18, Bryan Perry pisze:
> Since getting this library functional in May I have had roughly 6 to 8
> instances where the Kea process just dies and goes away. I am not sure
> why or if it is an issue with my library, kea itself or the CentOS
> machine it's running on. After the first two instances of this happening
I'm very sorry to hear that. Are you willing to share more information
about this, possibly off the list? I'm not aware of any issues in Kea
that would cause such a termination.

Do you have the log files Kea produced immediately before the process
died? Was it happening randomly or after very long operation? Are you
sure your MySQL DB was always on-line? In Kea 1.0 we implemented a
mechanism that when DB connection issue is encountered, Kea logs the
problem and terminates (because without DB connection it can't do
anything useful anyway and remaining in that state would be difficult to
spot.). Maybe that was the case? If not, I'm more than willing to spend
some time trying to debug the issue, if you're interested.

> On the shared subnet handling I have another scalability challenge in my
> network. The upstream router that is acting as my DHCP relay will always
> send the client request from its primary IP address. This even killed
> regular DHCP lease responses from a second subnet since the request came
> from the first subnet ID. In order to get around this I had to enable a
> feature of that router that would try sending the DHCP requests from
> each secondary IP address after a DHCP request failure on the primary
> address. This works, but takes several seconds for the failure on the
> primary and then the request on the secondary. The time delay gets
> longer and longer the more subnets it has to get failures on while its
> going down the list. That's a painful delay trying to get an IP address
> on the network if you are in a subnet further down the list.
Are you talking about sending relayed messages towards the server?
That shouldn't work that way. The source IP address the relay uses to
send the packet from towards the server shouldn't matter. The important
part is what the relay puts into the giaddr field.

> The last requirement I have that has also been handled via the library I
> wrote for Kea has been logging lease assignments to a database for
> historical purposes (summons, subpoenas, etc.).
This can be handled by the forensic logging library. Yes, it's available
only for people who support Kea financially, but we need to fund Kea
development somehow.

> Basically, until the shared subnet functionality works in Kea the way it
> does in DHCPD I don't really have a choice but to use DHCPD and put
> lease reservations for my static customers in the config file. 
Understood. Thanks for sharing those details. These are very useful,
especially for the design phase for proper shared subnet solution.

>>> // subnet4_select.cc
>>>
>>> #include 
>>> #include 
>>> ...
Thanks for sharing the code. That's very useful. Have you considered
publishing it somewhere (github maybe)?

This approach works, but it covers only some of the use cases for shared
subnets. It's sufficient for your deployment, but may not be applicable
to other deployments. There are two limitations with this approach. The
first one is that you effectively turned this into a global reservation.
That means one host can't have reservations in different parts of your
network. If you only have fixed clients, that's fine. Another limitation
(which is more problematic) is that it does not allow dynamic
allocation, so you need a static entry for all of your clients (or they
will get the addresses from the first subnet).

I'm not complaining, simply pointing out its properties in case someone
tries to use this code for such scenarios.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Combining config files

[Tomek Mrugalski]

On 06/02/17 22:02, Thomas Markwalder wrote:
> On 2/6/17 3:38 PM, James Sumners wrote:
> Kea 1.2, due out this April, will support an include directive.  We have
> refactored the configuration parsing and the directive was one of the
> enhancements made. You will also be able to use C++ style comments and
> they won't have to start in column one anymore either ;)
Yes, both C (/* */) and C++ (//) comments are now supported. The C-style
comments can span multiple lines. May be useful for commenting out
blocks of the config. Bash comments (#) are still supported, but they're
probably less convenient to use as they technically break JSON
compliance and some editors get confused with them.

> https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#json
> 
> The code is available in our public repo on git hub if you want to try
> it out:
> 
> https://github.com/isc-projects/kea
Our internal tests show that the new code work fine, but please keep in
mind that the code from git may not be super stable. Also, if you
encounter any issues, please report them.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] PostgreSQL lease management

[Tomek Mrugalski]

W dniu 01.02.2017 o 22:09, James Sumners pisze:
> Is there a document that describes how the leases database is managed
> when it is stored in PostgreSQL? In particular, I want to look at the
> queries that are involved, so something like [1] would be great.
> 
> I want to devise a trigger to archive leases to another table when they
> are being reaped.
> 
> [1] —
> http://kea.isc.org/wiki/HostReservationsHowTo#QueriesUsedbytheKeaServer
Not in a such easy format to read, but the information is there.

The schema itself is available in
src/share/database/scripts/pgsql/dhcpdb_create.pgsql.

The actual queries Kea code uses are in 2 files:

src/lib/dhcpsrv/pgsql_lease_mgr.cc (for leases)
src/lib/dhcpsrv/pgsql_host_data_source.cc (for host reservations)

It's a C++ code, but SQL queries are there in plain text, just search
for "tagged_statements". One way to browse those files would be our
github repo: https://github.com/isc-projects/kea/

On one hand writing such a document is useful, but on the other hand
there's the danger of it being outdated without anyone noticing.

Hope that helps,
Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Need help defining custom options

[Tomek Mrugalski]

W dniu 31.01.2017 o 14:36, James Sumners pisze:
> Documentation wouldn’t be too difficult:
> 
> When the |data| field is a |string|, and that string contains the
> comma (|,|; U+002C) character, the comma must be escaped with a two
> reverse solidus characters (|\\|; U+005C). For example, the string
> |foo,bar| would be |foo\\,bar|.
> 
> However, I’m not sure that escaping is the best route. It is clear to me
> that the problem stems from the fact that the |data| property can either
> only be a CSV value or a binary value. My suggestion for a more robust
> fix would be to remove the |csv-format| property and replace it with a
> |format| property. The new |format| property could accept the string
> values: ‘csv’, ‘binary’, or ‘literal’. The default could remain ‘csv’,
> and the case under discussion would be ‘literal’. This would also
> provide the possibility for other value types in the future.
We thought about similar thing and discussed it some degree with the
team, but decided against it. There are couple reasons for that.
First, the parser would get very complicated. Keep in mind that we allow
custom options to have records and you can have multiple records in a
single option. The number of different ways to encode the same option
would grow significantly with all the implications of it. The
documentation would get more complex and some users would wonder whether
one way is better than another.

Finally, there's the argument of breaking up existing deployments. Kea
is relatively new software, but I like to believe that it is being used
in some deployments. The change you propose would break down existing
deployments. Also, Kea is using a JSON syntax that is easily generated.
There are systems built around Kea that generate the configuration.
Those would break down too and would have to be updated.

We did not promise to never change the syntax, but we will need a very
good argument why we're breaking compatibility with older configurations.

On a related note, the approach your proposed is a good idea and perhaps
we will implement it one day. But it is unlikely to happen in the near
future. Kea is developed by a very small team and our engineering
resources are very limited. If we spent some time on this, we would
improve existing feature. You could do the same you can do now, albeit
in more convenient way. On the other hand, if we spend time on
developing something new, we can enable things that were previously not
possible. That gives us a bias towards developing new features, rather
than refining existing ones.

Hope that explanation makes sense.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Need help defining custom options

[Tomek Mrugalski]

W dniu 31.01.2017 o 14:27, James Sumners pisze:
> Thank you for the proposed release date of 1.2; I may be able to get by
> with 1.1.0 until then. But now I have to ask, what sort of versioning
> scheme is Kea following? With the x.y.z format, it looks like the format
> is following semver.org. If that is case, then I would argue that this
We mostly follow the versioning convention used by other ISC products.
However, since Kea is a relatively new software that receives
significant new features with every release, we tend to change Y number
every time. Once the pace of development slows down and we announce ESV
(Extended Support Version) branch, we will start bumping up Z number.
ISC DHCP and BIND also do -PX (patchlevel X) and -RX (release X), but
the Kea code keeps changing too rapidly for that kind of stability.

We will only bump up the X component when something very major is added,
like adding failover or perhaps removing obsolete DHCPv4 support (don't
worry, that won't happen any time soon :).

> qualifies for a 1.1.1 release. And that wouldn’t need to wait another
> three months for release.
Adding another release is something we can do, but only if major issue
is discovered that cannot wait till the next planned release. That
typically means a security issue or a very serious bug that prevents
many deployments from operating normally. Sadly, this bug here is not
such a case.

Having said that, I may try to help you with this. Would you be willing
to run git version of the code? I can review the fix and it could be
ready in couple days. If not, would a patch backported to 1.1.0 be ok?

Tomek Mrugalski
ISC

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Option-82-based reservation with remote-id

[Tomek Mrugalski]

W dniu 31.01.2017 o 18:28, Rui Pedro Caldeira pisze:
> Hello, I'm using Kea 1.1.0 and i need to make reservations based in the
> both option-82 parameters, circuit-id and remote-id.

> I already know how to place the circuit id in the config file, but there
> is no place to place the remote id. Can anyone help me?
That's because reservations done by remote-id are not supported yet in
DHCPv4. In DHCPv6 you can try a trick - configure mac sources to use
remote-id. This will treat remote-id as MAC and then you can make a
reservation by hw-address (which would really be remote-id value). This
mechanism is available in DHCPv6 only.

Please let me know how badly you need this capability.

Tomek
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Query regd access controls

[Tomek Mrugalski]

W dniu 17.01.2017 o 19:58, Nandan Adhikari pisze:
> I am unable to see any option to configure known-clients or
> unknown-clients. 
Because there are none there currently.

> Ref: https://kea.isc.org/wiki/ConfigurationMigration#PoolAccessControl
> 
> Is there anyway I can manage the access controls? Any helping pointer
> would be really great.
Can you describe what exactly you want to do? Depending on what's your
goal is, there may be things that could be done. Here are couple things
to consider.

1. If you want to serve only known clients (e.g. a list of known
subscribers or registered devices), you can use host reservation for
that. You can define an empty pool, so clients not having a reservation
will be rejected completely.

2. If you want known clients to get different options, there is a way.
In the upcoming Kea 1.2 we will have the ability to define options for
pools. You can define a subnet with options for known clients, define a
pool in it with options for unknown clients and define reservations for
know clients for addresses that are outside of the pool. This way
clients that have a reservation will get whatever address was reserved
for them and the options specified for the subnet. Clients that don't
have a reservation will get an address from the pool and whatever
options were defined in the pool. Just remember that more specific
scopes "override" more generic scopes. Global scope is most generic and
can be overridden by subnet options. Subnet options can be overridden by
pool options, which in turn can be overridden by host specific options.

The code for having pool options is available in git repo. It hasn't
been tested thoroughly, but you're more than welcome to try it.

3. If you want to have a completely generic way of assigning clients to
"unknown" and "known" classes, you'll need to write a hook for it. It
shouldn't be too complex, but you will need some C++ experience. The
hook should be installed on pkt4_receive hook point. You can then
inspect the query4 parameter and check whether there's a lease for the
value client sent in ciaddr field. Alternatively, you can install a hook
on lease4_select, but it will be a bit more tricky to determine whether
that's a new lease or existing lease being renewed. There's no one
correct choice here. It all depends on what you're trying to accomplish.

Ok, I suppose that's it. Does any of the above answer your question?

On a related note, the page you referenced is 3 years old. It probably
requires some refresh.

Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] mysql connection in hooks

[Tomek Mrugalski]

W dniu 08.12.2016 o 21:45, Igor Smitran pisze:
> Any info on mysql structure inside hooks feature request?
> 
> That way we would have generic sql structure no matter what database we
> use, right?
The #3457 ticket (http://kea.isc.org/ticket/3457) is phrased in a way to
make the generic connection available to hooks. Depending on the backend
you're using, that will be MySQL, PostgreSQL or even Cassandra specific
handle. We will decide the exact way of making this object available
once we get to the ticket.

As you may have noticed, this ticket is in Outstanding milestone. These
are tickets that nobody works on and they're not part of the current
(which is Kea1.2) or any other dedicated milestone. So it's very
unlikely anyone will work on it.

It may be disappointing as the ticket was submitted 3 years ago, but the
sad reality is that we currently have 345 tickets in the same
situation... It's better than what we had when we started 1.0 milestone
(I remember north of 450 tickets), but there's still a lot of
outstanding things to do.

Tomek Mrugalski
ISC

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Meaning of "client-class" in subnet?

[Tomek Mrugalski]

I think nobody responded to this so far, so here it goes.

W dniu 06.11.2016 o 05:47, mro...@insiberia.net pisze:
> When using "client-class" in a subnet, I understand it will associate
> all clients that are a member of that class with the subnet in question.
No. First, clients (or more precisely the packets sent by those clients)
are being classified and some may be assigned one or more classes. Then
Kea does normal subnet selection, based on the topology. This is
explained in Section 7.5
(http://kea.isc.org/docs/kea-guide.html#dhcp4-subnet-selection). If you
define client-class for a subnet, it acts as a white list. In other
words, only those clients that belong to specified class are allowed to
use that subnet.

> Documentation doesn't make it clear if it makes the subnet exclusive to
> that client class or not?
Yes, if class is defined, the subnet becomes exclusive for that client
class. To use a subnet with defined client-class, the incoming packet
has to be both topologically correct for the subnet AND belong to the
client class.

> In other words, would other clients be able to obtain addresses in that
> subnet?
No.

Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Default configuration for kea-lfc

[Tomek Mrugalski]

W dniu 19.11.2016 o 18:21, Patrik Lundin pisze:
> I have noticed that the example kea.conf in 1.1.0 does not configure
> a lfc-interval, meaning kea-lfc is disabled. Are there any reasons you
> would ever run without LFC in normal production situations, since this
> means you will (eventually) fill the partition that hosts the lease
> file?
No. LFC is reasonable to be enabled every time a memfile backend is
used. It is not needed for MySQL, PostgreSQL or Cassandra.

> If you generally are expected to run with LFC then I guess it would be
> helpful to either specifically set a lfc-interval in the configuration
> example as a hint to users, or go one step further and automatically set
Yes, that's a good suggestion. Can you open up a ticket for it?

> lfc-interval to some middle-of-the-road timeout when the database type
> is memfile and no specific lfc-interval is configured.
That would be good. One problem with its implementation is that the way
our current configuration parsers are implemented is messed up. The code
creates an independent parser object for each scope (a list, object or
JSON entry). This approach caused us to have lots of small parsers that
are able to parse specific part of the config. The side effect is that
the parser objects are only created for entries that are present in the
config file, which makes default values for entries not present
difficult to implement. We did several workarounds for that, but they
are kludgy at best.

The good news is that we're aware of the problem and decided to devote
significant part of upcoming 1.2 release to refactor, or even partially
rewrite the configuration parsers. Having the ability to specify default
values is certainly in scope of that work. See item #6 in ticket #5014
(http://kea.isc.org/ticket/5014).

To wrap this up, if you open a ticket, I can have the configs updated in
no time. Fixing the default value will take longer, but that's
definitely something we will have fixed in 1.2.

Tomek Mrugalski
ISC

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Option 82 Remote-ID

[Tomek Mrugalski]

W dniu 10.10.2016 o 18:16, Sylvan Miles pisze:
> Is it possible to get the Remote ID written to the database when a lease
> is written?
I presume you're asking about DHCPv4, right? It's not possible with the
current code. You would need to write a hook for that. Depending on how
flexible you want it to be, that may be anything between easy and very
complex.

In v6 you can use a trick that could possibly put remote-id in your
database. You can treat Remote-ID as a MAC address. If the Remote-ID
option is present, Kea would extract its content and put it in the
hwaddr field of each lease.

For details of this, see Section 8.9:
http://kea.isc.org/docs/kea-guide.html#mac-in-dhcpv6

Hope that helps,
Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Mozilla sponsorship of Kea

[Tomek Mrugalski]

W dniu 06.10.2016 o 16:33, Shane Kerr pisze:
> Thanks to Mozilla, and congratulations to the Kea team! :)

W dniu 07.10.2016 o 09:05, Chaigneau, Nicolas pisze:
> That's great news. And well deserved! :)

Thank you for your kind words. Yes, we're very excited about that.
Personally I'm very happy about the prospect of having the parsers
rewrite funded. This part of the code definitely could use a serious
clean up. I'm looking forward to actually make that happen.

Tomek

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Host Reservations and Subnets

[Tomek Mrugalski]

W dniu 04.10.2016 o 09:22, Rui Pedro Caldeira pisze:
> Hello Kea users list, I once seek your guidence.
> 
> I'm currently building a system that does not rely in the notion of
> subnet. Instead relies purely on host reservations via relays that can
> assign any IP possible. I can see that version 1.1.0 brought very nice
> features like library parameterization, reservations via DCHP option 82
> relay data (section 7.3 of Kea Administrator Reference Manual) and the
> possibility to insert options (such as default gateway) in the
> reservation itself (section 7.3 of Kea Administrator Reference Manual).
> My question is if I can configure Kea only with reservations (without
> subnets)?
You can't. Subnets represent topology of the network. If your network is
completely flat, you could define a single subnet, make sure that this
single subnet is always selected (either use interface parameter or
specify relay ip address) and then define all reservations in that
subnet. If you don't want to have any dynamic allocations, you can skip
the pools definition. This would give you completely static setup - only
clients with reservations would get an address.

If you're interested in rationale behind this approach, here's a bit of
background information. In the old ISC DHCP implementation all
reservations were global. In deployments that have many subnets with
many reservations in each, the code has to search in the whole list of
reservations, which has performance implication. Even worse, if there
are networks with mobile clients that have reservations in multiple
subnets, the search could result in multiple reservations, and one of
them has to be chosen for a particular request being replied to.

To avoid those problems, we made the reservation subnet-specific. It's
more efficient and seems more natural this way. If host X visits subnet
Y, it should get this set of parameters and addresses. If you have
mobile client, you can define independent set of parameters in each
subnet it is expected to visit.

Hope that helps,

Tomek Mrugalski
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Classless static routes?

[Tomek Mrugalski]

W dniu 30.09.2016 o 23:08, Sylvan Miles pisze:
>
>  
>
> Is it possible to hand out classless static routes with Kea (I’m
> running 1.1.0)?
>
Sure. Kea does not provide its definition, but you can do that easily
with custom option defintions.
>
>  
>
> DHCP option 121 under defined under RFC3442.
>
>  
>
> If not, is it on the roadmap or can it be added as a feature request?
>
It currently isn't. We can do custom option for now, but it would be
useful to have proper support for it. Can you create a new ticket for
it? Please go to kea.isc.org, log in (create an account if you don't
have one) and create new ticket for it. We will triage it and assign to
a milestone.
>
>  
>
> If so, what would the relevant kea.conf look like?
>
There are couple ways you can get it. The one you provided - to define
everything as integers - would surely work, but it's a bit cumbersome.
Here's a slightly more convenient one:

"option-def": [
{
"name": "classless-static-routes",
"code": 121,
"space": "dhcp4",
"type": "record",
"record-types": "uint8,uint8,uint8,ipv4-address"
 }],

"option-data": [
{
"name": "classless-static-routes",
"data": "9,10,0, 172.25.16.1"
}],   

You can probably skip the "space:" "dhcp4" part, but I have not tested
it. If you want to add multiple entries in that option, adding "array":
true may be useful.

The option-def has to be defined in the global scope of Dhcp4, while
option-data can be defined anywhere you need it: in the global or subnet
scope or even in host reservations if you want to provide different
values to different hosts.

The definition above assumes that the netmask will be between 9 and 16,
so the actual network part will be encoded on 2 bytes, hence the
uint8,uint8,uint8. If you want to define 10.0.0.0/8 for example, you'd
need to use "uint8,uint8, ipv4-address".

If you want to know more, this topic is discussed in detail in the Kea
User's Guide, in section 7.2.9 "Custom option definitions". You probably
want to take a look at the Table 7.3, too.

If you need a full working example, I have uploaded one here:
http://kea.isc.org/~tomek/cfg/stateless-class-routes.conf

Hope that helps.

Tomek Mrugalski
ISC

___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users