... | ... | @@ -30,8 +30,8 @@ Depending on the backend's capabilities, one or another allocator will be select |
|
|
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);
|
|
|
Lease4Ptr findAvailableLease4(IOAddress range_start, IOAddress range_end, uint64_t attempt_count);
|
|
|
Lease6Ptr findAvailableLeaseNA(IOAddress range_start, IOAddress range_end, uint64_t attempt_count);
|
|
|
... prefix delegation TBD ....
|
|
|
```
|
|
|
|
... | ... | @@ -46,9 +46,9 @@ 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 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 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.
|
|
|
The third 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.
|
|
|
|
|
|
# Memfile
|
|
|
|
... | ... | @@ -79,10 +79,13 @@ The `attempts_count` is used by the backend assisted allocator to determine when |
|
|
|
|
|
Note that the `attempts_count` is set per packet (also per thread). It is obviously reset to 0 when the new packet comes in.
|
|
|
|
|
|
The U-container must have an ordered index by IP addresses so as the backend can efficiently access available addresses within different IP ranges. In order to avoid iterative allocation (e.g. 192.0.2.1, 192.0.2.2...), there should be another index created which holds unique hashes computed from the IP addresses. It makes it possible to order the result set containing multiple IP addresses according to the hash, thus offering the leases in the hardly predictable order of addresses. Different backends may apply different hashing functions. In fact, it may even be extensible and the hashing algorithm could be configurable if we choose to do so.
|
|
|
The U-container must have the following indexes:
|
|
|
- ordered index sorting elements by IP address - to be able to efficiently remove a lease which got allocated,
|
|
|
- sequenced index which can be used as bi-directional list that puts the free addresses in the order in which they will be offered to the allocator.
|
|
|
|
|
|
The contents of the U-container are not persisted. They are stored in memory only. If the server is restarted the A-container is restored from the lease file, the pools are read from the configuration storage and finally the U-container is recreated using combined information from the A-container and the pools' configurations.
|
|
|
|
|
|
|
|
|
## Pools Configuration
|
|
|
|
|
|
There are several different ways to configure pools to be served by a Kea server:
|
... | ... | |