... | ... | @@ -28,6 +28,8 @@ Depending on the backend's capabilities, one or another allocator will be select |
|
|
|
|
|
```c++
|
|
|
uint8_t getLeaseSelectionSupport() const;
|
|
|
void preallocateLeases4(IOAddress range_start, IOAddress range_end);
|
|
|
void preallocateLeases6(IOAddress range_start, IOAddress range_end);
|
|
|
Lease4Ptr findAvailableLease4(IOAddress range_start, IOAddress range_end, IOAddress last_offered, uint64_t attempt_count);
|
|
|
Lease6Ptr findAvailableLeaseNA(IOAddress range_start, IOAddress range_end, IOAddress last_offered, uint64_t attempt_count);
|
|
|
... prefix delegation TBD ....
|
... | ... | @@ -42,6 +44,8 @@ const uint8_t LEASE_SELECTION_PD = 0x04; |
|
|
const uint8_t LEASE SELECTION_ALL = 0x07;
|
|
|
```
|
|
|
|
|
|
The `preallocateLeases4` and `preallocateLeases6` functions are to be triggered upon the server's first configuration, reconfiguration or configuration update for individual address pools for which preallocation should take place. As a result, the backend specific implementations will create appropriate lease entries to mark those that are available.
|
|
|
|
|
|
The remaining functions are used by the allocation engine to get the next available lease of a given type for a given pool. The pool is specified as a pair of IP addresses denoting the beginning and the end of the pool. The third argument designates the last offered lease for the given pool. The allocation engine maintains the pointers to the last offered addresses for the individual pools. Providing the last offered address and properly updating it within the allocation engine's allocator guarantees that the backend will avoid returning the same address when the allocation engine makes subsequent attempts to get an available address for a client.
|
|
|
|
|
|
The forth argument is a counter of attempts made to get an available address for a given client/packet. It should be set to 0 upon the first attempt and incremented when the offered address is rejected by the allocation engine and another attempt is made.
|
... | ... | @@ -88,7 +92,12 @@ There are several different ways to configure pools to be served by a Kea server |
|
|
|
|
|
A change in the pools configuration should trigger an action of pre-allocating the leases for the updated pools. Pre-allocation may be a time consuming operation depending on the size of the pools configured. The server should be able to verify if the latest configuration change affected any pools. If no pools have been modified as a result of the reconfiguration, the pre-allocation step should be skipped. If only some pools have been modified, the pre-allocation should be performed only for the modified pools.
|
|
|
|
|
|
...
|
|
|
There is no standard way in which the pre-allocation could be triggered for all configuration methods listed above.
|
|
|
|
|
|
When the server is reloaded, the server should be able to compare the old and new configurations and detect which pools have been added. The `preallocateLeasesX` function should be executed as a final configuration step for all new pools. We could potentially make such checks during the commit() call on the `CfgMgr`, but a PoC would be needed to confirm whether it is a good idea.
|
|
|
|
|
|
The subnet_cmds and configuration backend add/modify subnets directly to the current config (not staging config), and that doesn't involve a commit phase. Therefore, we'd need to trigger `preallocateLeasesX` whenever they update the current config directly. Again, determining the best place to trigger pre-allocation is to be determined.
|
|
|
|
|
|
# MySQL and Postgres
|
|
|
|
|
|
The SQL backends store information about allocated leases in the `lease4` and `lease6` tables. Similarly to the Memfile backend, finding an available lease using the information about allocated leases is inefficient and thus storing the information about unallocated leases is required.
|
... | ... | |