Shared network thresholds

[Niall O'Reilly]

On 22 Nov 2016, at 21:00, Simon Hobson wrote:

> project722 <project722 at gmail.com> wrote:
>
>> When I implemented the shared network for this market, the primary 
>> subnet 192.168.100.0 was around 80% max. Its now at 90% and still 
>> climbing. The secondary is taking on leases but I want to know what 
>> logic controls whether or not new turn-ups get addresses from the 
>> primary or secondary?

   What Simon wrote (mostly quoted below).  I have a few comments to 
add.

   The (human) labels "primary" and "secondary" cannot be expressed in 
the configuration,
   and so may just be distractions.

>> Is there an option or directive I can add to tell dhcpd to hover 
>> around the 80% mark on the primary?

   I don't believe there is.  Simon's idea of introducing dummy leases 
is a neat trick,
   but I would be too lazy to go to that much trouble. 8-)

>> What's going to happen if dhcpd maxes it out?

   Unless both pools become maxed out, nothing noticeable.

>> I'm sure new turn-ups would go into the secondary pool but I'd like 
>> to have at least a 15% buffer.

   The dhcpd code allocates leases from the pools belonging to (the 
subnets of) a shared network
   pretty-much as if a single aggregate pool were available, provided 
that all clients are eligible
   for allocation from each pool.  As long as there's headroom 
somewhere, you don't have to be
   concerned about having specific headroom in each pool.

   Only if you use some client property to select one or the other pool, 
do you need to worry
   about having headroom in each one.

> There is a defined method for allocating leases. The allocation 
> routine follows this order :
>
> 1) If the client requests a specific address, and this is available 
> for it, then it is given.
>
> 2) If the client previously had an address, and this address is still 
> available to be given to the client, then it is offered.
>
> 3) If there are any "never used before" addresses, then one is picked 
> according to an undocumented internal process. At the moment, the 
> internal hashing process results in them being picked "top down" - but 
> this is liable to change at any time without notice so don't rely on 
> it.
>
> 4) A previously used address is picked on a least recently used basis 
> - ie the address that has been in the free state for longest.
>
> 5) If there are any abandoned leases, then the server will test to see 
> if any of them can be recovered.
>
> 6) If you reach here - there's nothing to give the client so it fails.
>
> In your case, I'd have expected step 3 to mean the second subnet 
> filling up, so I'm not sure what's going on.

   Me too, but an idea occurs to me.

   If OP has obfuscated the addresses, it could be that one of the 
"primary" pools is actually
   "nearer the top" of the hash table than the corresponding 
"secondary".


   Best regards,

   Niall O'Reilly