pool range utilization

[Yannick CHAMPS]

Hi all,

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 ?
What is the dhcpd's criteria to load balance leases upon pool ranges  ?


shared-network Network-nat {

     option domain-name "acme.com";
     option domain-name-servers  8.8.8.8,8.8.4.4;
     default-lease-time 360;
     max-lease-time 360;


         subnet 172.16.128.0 netmask 255.255.192.0 {
                 option subnet-mask              255.255.192.0;
                 option broadcast-address        172.16.191.255;
                 }
          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";

              }
                             }



#dhcpd-pools -c /etc/dhcpd.conf -l /var/lib/dhcpd/dhcpd.leases
Ranges:
shared net name     first ip           last ip            max cur    
percent  touch   t+c  t+c perc

Network-nat        172.16.128.1     - 172.16.135.255    2047 0      
0.000      0     0     0.000
Network-nat        172.16.136.1     - 172.16.143.255    2047 9      
0.440      0     9     0.440
Network-nat        172.16.144.1     - 172.16.151.255    2047 92      
4.494     10   102     4.983
Network-nat        172.16.152.1     - 172.16.159.255    2047 223    
10.894      3   226    11.041

--
Yannick

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[sthaug]

> 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 ?

Why do you care? With your configuration you have told the DHCP server
that it can use all four specified ranges.

> What is the dhcpd's criteria to load balance leases upon pool ranges  ?

There is no "load balancing" among ranges that you can count on.

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Yannick CHAMPS <[hidden email]> 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 ?

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Yannick CHAMPS]

I have to balance my wan traffic over 4 links.
If some pools are more used than others, then some wan link as more
loaded than others.

Yannick

On 29/04/2015 19:51, [hidden email] 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 ?
> Why do you care? With your configuration you have told the DHCP server
> that it can use all four specified ranges.
>
>> What is the dhcpd's criteria to load balance leases upon pool ranges  ?
> There is no "load balancing" among ranges that you can count on.
>
> Steinar Haug, Nethelp consulting, [hidden email]

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Yannick CHAMPS]

Thank you for this clarification. But reducing the poll range size is
not the best option for me. But if it is the only solution I will give
it a try.
I have answered before to Steinar about my motivation.

I don't need to provide router address, we use isc dhcpd in a 4G
network, there is a virtual tunnel that sends all traffic to gateway.

--
Yannick

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Yannick CHAMPS <[hidden email]> wrote:

> But reducing the poll range size is not the best option for me.

That's not suggested as a permanent change - just to spread the clients during the initial phase of address assignment. So to start with, you might try :

  pool {
              range 172.16.128.1 172.16.130.255;
              range 172.16.136.1 172.16.137.255;
              range 172.16.144.1 172.16.145.255;
              range 172.16.152.1 172.16.153.255;
              allow members of "lte_internet";
           }
and monitor the pool utilisation closely - in this case, I've left more on teh lower numbered range to give a little bit of leeway). The 3 higher numbers ranges will fill up fairly fast, and as the lowest one starts to fill, you add address to all the ranges :
  pool {
              range 172.16.128.1 172.16.131.255;
              range 172.16.136.1 172.16.138.255;
              range 172.16.144.1 172.16.146.255;
              range 172.16.152.1 172.16.154.255;
              allow members of "lte_internet";
           }
rinse and repeat ...

That will spread new clients across the ranges, and will also spread "old" leases (addresses that have been used, but the client has gone away) across the ranges. Over time, the pool utilisation will become as close to random as you are likely to get - and with large numbers of users, your link utilisation will probably be statistically even.
But be aware that this will not achieve load balancing as such, just something that overall gives something with that appearance.


I have thought of another option. If you create dummy leases for every address in your ranges, each flagged as expired and with random end times, then that would also prime the system with random lease assignments. But you'll need to knock up a script to create the extra leases - they only need very basic information, just enough to make the DCHP server load them and treat the addresses as used.
I don't know if the leases need to have a hardware address in them, if they do, then try and use a range of dummy addresses that are unlikely to be found in practice - I don't know if there is a reserved range of MAC addresses for experimental or documentation use.



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

I wrote:

> 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.

Oops, as has been pointed out to me off-list, that should say "not guaranteed to not change".
Ie, it's simply an artefact of the way the addresses are hashed internally, and it could change at any time without any notice (since it's not a change in any documented feature, it might not even be in the release notes).
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ruben Wisniewski]

Am Thu, 30 Apr 2015 07:40:27 -1000
schrieb Yannick CHAMPS <[hidden email]>:

> I have to balance my wan traffic over 4 links.
> If some pools are more used than others, then some wan link as more
> loaded than others.
>
> Yannick

I think you should use iptables with a hashtable for the client-ips for
selecting one of the wan-links. That would spread the load more easily.
Else you can take one of the links down without the need to reorganize
the lan behind your router.


Best regards


Ruben

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users