Please sign in to comment.
PostgreSQL: Don't require a lease to have expired if we reallocate it…
… to the previous client The current default allocate_find query causes per-client IP allocation instability that starts when allocate_clear rate limiting comes into effect. With initial pool conditions the default alloc_find query selects from the pool of all *expired* leases. It selects the least recently used IP address (i.e. the one with the oldest expiry_time) unless a matching username and/or callingstationid exists in the table in which case these are prioritised in order to issue the client with their previous lease. Normally picking the least recently used address helps to avoid issuing the address to a different client, maximising the chance of stickiness, which is desirable. However, if a user makes successive authentication attempts whilst allocate_clear rate limiting is active they are always allocated a different IP address because their existing address is unavailable (has not yet expired and has not been explicitly expired by allocate_clear), with the effect that there are now multiple rows in the table containing the same pool_key, username and callingstationid. The normal ordering then has the undesirable effect of ensuring that successive future IP address selections for the client will flip-flop between addresses because username + callingstationid are first prioritied then the *oldest expiry_time* is chosen (rather than the most recent expiry relating to the most recent lease). This behaviour persists once allocate_clear rate limiting is no longer in effect. We can avoid getting having multiple rows with the same client details by amending the allocate_find query to include an existing row matching nasipaddress and pool_key in the available set of IP addreses regardless of whether the lease has expired or not (i.e. re-allocation of a current lease to the same client).
- Loading branch information
Showing with 4 additions and 1 deletion.