pool range utilization

[Simon Hobson]

Yannick CHAMPS <yannick at viti.pf> wrote:

> do you know why the 1st pool range (172.16.128.1 to 172.16.135.255) is not used at all even if all pool ranges share the same configuration ?

Because it's an artefact of the implementation that "never used before" addresses get allocated in a specific order - which happens in the current implementation to be "top down". That isn't documented, and it's not guaranteed to change.

Once there are no addresses left which have never been used before, then "previously used but now free" addresses are recycled on a least recently used basis. Once that happens, then address assignment will start to gain randomness.

If you specifically wanted to create some spread in the initial usage, then start with smaller ranges and expand them as they get used.

But as Steinar Haug says, why does it matter ?

>         pool {
>                range 172.16.128.1 172.16.135.255;
>                range 172.16.136.1 172.16.143.255;
>                range 172.16.144.1 172.16.151.255;
>                range 172.16.152.1 172.16.159.255;
>                allow members of "lte_internet";
>             }

I am however, very slightly curious as to why you've defined the pool like that ? Why not one big range (172.16.128.1 to 172.16.159.255) ?

I have seen people advocate changing (say) :
> 172.16.128.1 172.16.129.255

to
> 172.16.128.1 172.16.128.255
> 172.16.129.1 172.16.129.255
but the reason for that (p*ss poor client implementations that assume .0 and .255 addresses aren't valid) is old and probably no longer relevant, plus you've included plenty of them in your current ranges.

As an aside, what are the router addresses, you don't seem to defined any ?