<div dir="ltr">Hi Tomek,<div><br></div><div>Are you referring to VRF support when you say Multi-Tenancy?</div><div>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.</div><div><br></div><div>Cheers,</div><div>Jason</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 8:24 AM, Tomek Mrugalski <span dir="ltr"><<a href="mailto:tomasz@isc.org" target="_blank">tomasz@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rob,<br>
<br>
I did a little experiment. With a bit of code tweaking, I managed to<br>
force Kea to load two identical subnets that only differed in relay IP<br>
address. It started all fine and I was able to get leases in each subnet.<br>
<br>
There's one major caveat, though. Allocation engine, the core part of<br>
the code that picks leases for new clients, can't tell a difference<br>
between them and thinks the address is used, despite it being used in<br>
the other subnet.<br>
<br>
My subnets defined were 192.0.2.1 - 192.0.2.200. First client in the<br>
first subnet got 192.0.2.1 (as expected), but the second client in the<br>
second subnet got 192.0.2.2, not 192.0.2.1.<br>
<br>
If your subnets are large (e.g. <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a>) you may not care. If they're<br>
smaller, you'll use up all addresses real quick.<br>
<br>
To implement it properly, we would have to remove getLeases4(addr) call<br>
and implement getLeases4(addr, subnet-id) instead. There's tons of uses<br>
of getLease4(addr) throughout the whole code (around 200 instances).<br>
This would require a MAJOR rework of Kea code and the reworked code<br>
would probably we worse than it is now. So am afraid it's unlikely to<br>
happen. At least in official master. I can imagine you hacking Kea code<br>
similar way you did dhcpd would be somewhat realistic, if you accept<br>
that certain things will be broken.<br>
<br>
Keep in mind that tweaking the code to allocate the leases is only the<br>
first step on this dark and twisted path. The next step that will<br>
probably not work is lease renewal. Then release release. After that<br>
you'll face probably broken lease expiration. Commands related to leases<br>
won't work etc. You can end up with all sorts of messed up situations,<br>
like client from one network renewing a lease from another subnet, then<br>
his lease expiring because not being renewed.<br>
<br>
If you really want to go that path, here's a page that described my<br>
experiment: <a href="http://kea.isc.org/wiki/KeaMultiTenant" rel="noreferrer" target="_blank">http://kea.isc.org/wiki/<wbr>KeaMultiTenant</a><br>
<br>
Tomek<br>
______________________________<wbr>_________________<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/kea-users</a><br>
</blockquote></div><br></div>