... | ... | @@ -114,6 +114,79 @@ The trigger should be added on the `lease4_avail` table to delete entries as a r |
|
|
|
|
|
*IPv6 to be described*
|
|
|
|
|
|
## Pseudo Random Lease Selection
|
|
|
|
|
|
Randomizing available lease selection from the pool can be achieved by adding a hashing column to the `leaseX_avail` tables.
|
|
|
|
|
|
The following query is the extension of the query provided in the previous section which besides inserting available addresses would also add md5 digest to the table:
|
|
|
|
|
|
```sql
|
|
|
WITH avail_addresses AS
|
|
|
(SELECT avail FROM generate_series(('192.0.2.10'::inet - '0.0.0.0'::inet),
|
|
|
('192.0.2.100'::inet - '0.0.0.0'::inet), 1) AS avail
|
|
|
LEFT JOIN lease4 on avail = lease4.address
|
|
|
WHERE lease4.address IS NULL)
|
|
|
INSERT INTO lease4_avail (address, address_hash)
|
|
|
SELECT avail, md5(avail::text)
|
|
|
FROM avail_addresses;
|
|
|
```
|
|
|
|
|
|
where `lease4_avail` is created as follows:
|
|
|
|
|
|
```sql
|
|
|
CREATE TABLE lease4_avail (
|
|
|
address bigint NOT NULL PRIMARY KEY,
|
|
|
address_hash text NOT NULL
|
|
|
);
|
|
|
CREATE UNIQUE INDEX lease4_avail_address_hash_unique ON lease4_avail(address_hash);
|
|
|
```
|
|
|
|
|
|
Then the query similar to this can be used to retrieve next available address:
|
|
|
|
|
|
```sql
|
|
|
SELECT * FROM lease4_avail
|
|
|
WHERE address >= 3221225994 AND address <= 3221226084
|
|
|
AND address_hash > md5(3221226082::text)
|
|
|
ORDER BY address_hash;
|
|
|
```
|
|
|
|
|
|
where `3221226082` is the integer representation of the last IP address returned for the given pool. The `3221225994` and `3221226084` designate the pool range.
|
|
|
|
|
|
This is the example order in which the addresses from the 192.0.2.10 to 192.0.2.100 are returned for such hashing algorithm:
|
|
|
|
|
|
```
|
|
|
address
|
|
|
-------------
|
|
|
192.0.2.71
|
|
|
192.0.2.91
|
|
|
192.0.2.70
|
|
|
192.0.2.90
|
|
|
192.0.2.42
|
|
|
192.0.2.47
|
|
|
192.0.2.23
|
|
|
192.0.2.72
|
|
|
192.0.2.76
|
|
|
192.0.2.51
|
|
|
192.0.2.28
|
|
|
192.0.2.38
|
|
|
192.0.2.64
|
|
|
192.0.2.14
|
|
|
192.0.2.36
|
|
|
192.0.2.53
|
|
|
192.0.2.43
|
|
|
192.0.2.21
|
|
|
192.0.2.50
|
|
|
192.0.2.60
|
|
|
192.0.2.87
|
|
|
192.0.2.99
|
|
|
192.0.2.17
|
|
|
192.0.2.57
|
|
|
192.0.2.78
|
|
|
192.0.2.37
|
|
|
192.0.2.100
|
|
|
...
|
|
|
```
|
|
|
|
|
|
## Considerations About Multiple Kea Instances
|
|
|
|
|
|
It appears to be a common use case to have multiple Kea servers connected to the same database. These servers share lease information in the `lease4` and `lease6` tables. The SQL trigger mechanism addresses the problem of consistency between the `leaseX` and `leaseX_avail` tables during normal operation. The aspect which requires some consideration is the servers' startup and reconfiguration phases.
|
... | ... | |