[Kea-users] Multiple Subnets - 1 NIC

[Maxime Lareo]

I found the problem, for the actual stable KEA version, the interface 
option doesn't solved the problem, its been solved in the dev KEA 
version, the master branch of the github project, and it seems to be 
solved with this commit : 
https://github.com/isc-projects/kea/commit/7c74ecdbb64c69d341d623422216b0a54e6ff519 


I tested it with the current dev KEA version, usage of the interface and 
the client class options together is doing the job to select a subnet. I 
also tested with the stable KEA version built with the change brought in 
this commit, it also worked properly, so it definitely this commit who 
fixed this problem.

So until the next release, KEA 1.1.0, client classification and 
interface options will not be used in the subnet selection process. KEA 
will just keep looking for the first local interface IP address to 
select a subnet for a direct client.

One more question, why KEA is not taking host reservation in account to 
select subnet ?
KEA seems to be able to find every host reservation in every subnet for 
a client, but for now this step coming after the subnet selection and if 
the ids of the subnets doesn't match the first selected subnet id KEA is 
ignoring the host reservations. Is it wanted ?
Perhaps an option to enable this behavior, I mean when KEA find a host 
reservation it can change the selected subnet for the one with the 
reservations, it could be useful.

Thank you for your concern.
Max

On 16/08/2016 16:51, Tomek Mrugalski wrote:
> W dniu 16.08.2016 o 09:01, Maxime Lareo pisze:
>> Hi Klaus,
>>
>> Thank you for your quick answer,
>>
>> What do you mean by 'the subnet as one that's owned by Kea', the one the
>> NIC belong to ?
>>
>> I have different scope for my subnets, here is a part of my config :
>>
>> --->8---
>>
>> "client-classes": [{ "name": "VoIP", "test":
>> "substring(option[60].hex,0,6) == 'Aastra"}],
>>
>>   "subnet4": [
>>    {
>>     "id": 1,
>>      "client-class": "VoIP",
>>      "pools": [{"pool": "192.168.4.10 - 192.168.4.50"}],
>>      "subnet": "192.168.4.0/24"
>>    },
>>    {
>>    "id": 2,
>>     "pools": [{"pool": "192.168.10.160 - 192.168.10.180"}],
>>     "subnet": "192.168.10.0/24"
>>    }
>> ]
>>
>> ---8<----
>>
>> The IP adress of my server is 192.168.10.100/24  and I tried to use an
>> interface alias to add the IP address 192.168.4.100/24 to my server. I'm
>> sure that the Ip phones belong to the class VoIP, I see it in the kea
>> log file, but it still doesn't working...
>>
>> All devices are connected on the same switch, and belong to the same VLAN.
>>
>> I also tried to use reservations to see if the subnet selection will be
>> affected by reservations but this is not the case, KEA find the
>> reservation but don't use it because it is not inside the subnet it
>> belong to.
>>
>> So I tried to use larger mask, like '/20' for the first subnet and use
>> the option 1 'subnet-mask', to make the KEA server part of this subnet,
>> but it seems not working because devices using the /20 and not the /24
>> specified into the subnet-mask option.
>>
>> I'm running out of ideas.
> client-class match is necessary, but not sufficient condition for Kea to
> select a given subnet. I don't know how your network is organized, but
> here are couple things you can try. If both are on the same link that
> Kea uses, you can add "interface": "eth0" to each subnet to tell Kea
> that those subnets are available locally. Replace eth0 with whatever
> interface you're receiving this traffic on.
>
> Try this:
>
>   "subnet4": [
>    {
>      "id": 1,
>      "client-class": "VoIP",
>      "interface": "eth0",
>      "pools": [{"pool": "192.168.4.10 - 192.168.4.50"}],
>        "subnet": "192.168.4.0/24"
>   },
>   {
>     "id": 2,
>     "interface": "eth0",
>     "pools": [{"pool": "192.168.10.160 - 192.168.10.180"}],
>        "subnet": "192.168.10.0/24"
>   }
> ]
>
> On a related note, I think we failed to document the "interface"
> parameter properly. For the time being, you may want to read Section
> 8.2.14 "IPv6 Subnet Selection" and apply that logic to IPv4. If that
> works, could you create a ticket on kea.isc.org regarding the v4
> documentation needing update?
>
> Finally, a general comment. Kea does not yet support shared networks in
> the sense ISC DHCPD does. You need some way to classify the incoming
> packet. Fortunately, you have that problem solved by using VoIP class.
> But for other people who would like to have two subnets on the same
> link, allocate addresses from the first one and then seamlessly start
> allocating from the other subnet - nope, that's not gonna work. At least
> not yet.
>
> Hope that helps,
> Tomek
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users