|
|
# Kea Multi-tenancy support
|
|
|
|
|
|
'''WARNING: This is just an experiment. Major mechanisms are likely to break down if you try it. Do not run in production! '''
|
|
|
|
|
|
Multi-tenancy is a property of DHCP server to handle multiple overlapping address spaces. A good real life example may be multiple hot spots, each serving the same private 192.168.1.0/24 address space. This functionality breaks down the fundamental principle most DHCP servers are built upon - no duplicate addresses allowed.
|
|
|
|
|
|
As of Kea 1.3, it does not support multi-tenancy. This page serves as a scratch pad for ideas, requirements and perhaps bits of a design discussing what would have to be changed in the code to make it possible.
|
|
|
|
|
|
Interested user: https://lists.isc.org/pipermail/kea-users/2018-March/001664.html
|
|
|
|
|
|
Experiment 1: using MySQL:
|
|
|
|
|
|
1. Alter the schema to remove address being primary key. Instead there would be composite key: PRIMARY KEY(address, subnet_id)
|
|
|
```
|
|
|
alter table lease4 DROP PRIMARY KEY;
|
|
|
alter table lease4 add PRIMARY KEY (address, subnet_id);
|
|
|
```
|
|
|
|
|
|
2. open file src/lib/dhcpsrv/cfg_subnets4.cc and edit out safety check. the code should look like this:
|
|
|
```c++
|
|
|
void
|
|
|
CfgSubnets4::add(const Subnet4Ptr& subnet) {
|
|
|
if (getBySubnetId(subnet->getID())) {
|
|
|
isc_throw(isc::dhcp::DuplicateSubnetID, "ID of the new IPv4 subnet '"
|
|
|
<< subnet->getID() << "' is already in use");
|
|
|
|
|
|
} // extra sanity check used to be here.
|
|
|
|
|
|
LOG_DEBUG(dhcpsrv_logger, DHCPSRV_DBG_TRACE, DHCPSRV_CFGMGR_ADD_SUBNET4)
|
|
|
.arg(subnet->toText());
|
|
|
subnets_.push_back(subnet);
|
|
|
}
|
|
|
```
|
|
|
|
|
|
and recompile.
|
|
|
|
|
|
3. Define the same subnet twice. Make sure it has different relay ip addresses. See attached config example.
|
|
|
|
|
|
4. Run kea: kea-dhcp4 -c multi-tenant.json
|
|
|
|
|
|
Send traffic from a client behind relay 10.1.1.1. It will get an address from subnet 1.
|
|
|
Send traffic from another client behind relay 10.2.2.1. It will get an address from subnet 2.
|
|
|
|
|
|
Problems:
|
|
|
the leases are still unique. First client got 192.0.2.1. The second one got 192.0.2.2, because Kea detected that there's a lease for the first address being considered: 192.0.2.1 and retried with the next one.
|
|
|
|
|
|
This would require altering AllocEngine::allocateOrReuseLease4 to not use getLease4(address), but use getLease4(address, subnet-id) and such a call is not implemented.
|
|
|
|
|
|
## Result (as of 1.3.0)
|
|
|
You can tweak Kea to accept multiple copies of the same subnet with a small patch that disables sanity checking. The proper solution will be to add a configuration knob to enable multi-tenancy and then if it's enabled, skip some sanity checks and do additional ones (like require that the other copy of existing subnet to have a different relay-ip address).
|
|
|
|
|
|
You can kind of make it work, but Kea will not be able to make a difference between subnets when checking if lease is available or not. Thus you'd end up eating up leases fast. If your pool is big enough (10.0.0.0/8) perhaps this would be acceptable.
|
|
|
|
|
|
To solve it properly, we'd have to:
|
|
|
- remove getLease4(addr) call. This will break down all sorts of things.
|
|
|
- add getLease4(addr, subnet-id). This will require updating all backends to support it (c++ code, the schemas, indices etc)
|
|
|
|
|
|
It's still a mystery how various parts of the code will react. Some will choke for sure. |