[Kea-users] Migrating from ISC DHCP

[Tomek Mrugalski]

W dniu 05.06.2017 o 10:46, Christian Kratzer pisze:
> Hi,
> 
> I am posting my experience from evaluation migration of an DHCP based
> FTTH setup from ISC DHCP to KEA.
> 
> After browsing through the available documentation and roadmaps I 
> identified a couple of issues.
Hi!

Thanks for looking into Kea and for sharing your use cases.

> 1. shared networks: -------------------
> 
> this is one is a show stopper for 1.2 as the setup makes extensive 
> use of shared networks. I was very happy to see shared networks on 
> the roadmap for 1.3 though.  I have started digging the trac
> database for details on individual milestones.  I would be happy to
> provide input, engage in discussion if possible and do early testing
> in our lab.  Not sure where the communication is currently taking
> place.

> I can also detail our use case in more depth if required but I think 
> ISC style shared networks with pools joined over multiple subnets 
> describes it quite well.
I'm currently working on a requirements document on this, but in general
it can be summarized as: do as close to isc dhcp as possible. I will
announce it on kea-dev in next couple days, asking for comments.

> 2. lease info and options: --------------------------
> 
> I was also quite happy to see a that a rest api for leases is in the
>  works for 1.3
> 
> The use case here is a bit more special.  We currently using option82
> circuit-id and remote-id with ISC DHCP not only to provide fixed
> addresses for host reservations but also to lookup agent options by
> ip in the isc lease database.  The main use case for this is so that
> the ACS (tr069 autoconfiguration) server can identifiy customer cpe
> by their line id.
> 
> ISC DHCP also stores agent options in the lease database which is the
> main feature that makes this possible.
> 
> We have subsequently hacked up OMAPI to include agent options in the
>  lease lookup.
> 
> For this to work in KEA we would need to have specific options
> stored in the lease.  Some early design documents I found seem to
> have thought of this but the current releae does not have anything.
That's true. We have thought about this initially, but for the time
being storing options with leases has not been implemented. This is
something we will need to do eventually. One reason is the use case you
mentioned. Being able to provide options when aswering leasequery is
another.

> What would my options be on adding this to KEA or getting a 
> workaround with hooks in place.
You didn't mention which backend you use. If it's MySQL or PostgreSQL,
you could extend the DB schema to add extra columns to store options and
then use lease{4,6}_select or perhaps pkt{4,6}_send to fill the column
with option values once the lease information is in place.

> I would like to add following options the the lease database for 
> ipv4: agent.circuit-id, agent-remote-id.
It's a bit easier if you can pick specific options. However, to solve
this problem in a generic way, we would need some sort of mechanism to
configure which options are to be stored.

> For ipv6 we currently use option 18 interface-id.  Due to the nature 
> of of v6 ldra design we would propably need to store the whole chain 
> of option 18 interface-id and option 37 remote-id into the lease 
> perhaps as an array.
> 
> Can this be done through a hook ?   I would provide a pull request
> if I succeed.
Yes, but it's a surprisingly complex topic. The trick is to have a
mechanism that is flexible enough for people who need different options.
Storing extra options has a performance penalty, so people who do not
need it would want to have this capability be disabled. Also, the
feature of storing options with leases should work for all backends.

I'm mentioning all of those not to disappoint you, but to give you an
advance warning. Sometimes people assume that "it works for me" implies
that the patch is good for everyone and are surprised that getting it
accepted is not as straightforward as it may look at the first glance.

> 3. isc style if statements in subnets. 
> --------------------------------------
> 
> We currently add specific options to replies in specific subnets only
> depending on further criteria like firmware version supplied in other
> options.
> 
> I started thinking about implementing this in KEA with classes and 
> matching those classes in host reservations included into the 
> specific sunets.  Would that work ?  Is my requirement clear enough 
> ?
While the exact logic behind if statement does not have direct
replacement in Kea, there are things you could do.

Keep in mind that the client-classes in reservations means that the
client is automatically assigned to said class if its identifier
matches. This would work if you have host reservations for all clients
(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