Steven Carr <
[hidden email]> wrote:
> On 27 October 2015 at 04:18, Roberto De Oliveira <
[hidden email]> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.
To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets are on the same network (broadcast domain). That explicitly means all IP addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an address from - which is the same for the case of a larger subnet and two pools within the one subnet.
A key thing to remember is that there is no such thing as "I receive packages from subnet 186.90.0.0" for broadcast packets. When a client is configuring itself, it has no IP address, so the concept of belonging to a specific subnet does not exist - the only "location" for the client is the broadcast domain which in the case of a shared-network hosts multiple subnets. When the server receives a packet from IP address 0.0.0.0, there just isn't any way to say it belongs to one subnet or another.
As an aside, this is also the reason you can't run a DHCP service on a sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to route that packet to the main interface (eth0) or the subinterface (eth0.1).
Only when a client has been allocated an address, and configured it's interface, does it "belong" to a specific subnet.
For a "fresh" install, the address allocation order is determined by the way the code works - which is not specified and liable to change without notice. At present this is a "top down" ordering where the highest numerical address is issued first.
Once there are no "never used before" addresses left, then addresses are re-used on a least recently used basis - at which point allocation takes on a pseudo-random appearance.
If a client requests a specific address, and that address is available, then that address will be given. So if there are clients which already had addresses on the network, then depending on how "clingy" they are, you will see "out of order" allocation of never used before addresses.
If you need specific clients to get addresses in specific pools, then you need to tell the server about your requirements. This may be as simple as defining host statements for certain clients and using allow/deny known-clients in the pools. Or it may be more complicated, using classes and possibly subclasses.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users