Weird behavior with multiple pool inside shared networks

[Roberto De Oliveira]

Thanks Simon,

Excellent explanation, I think that I have to rethink somethings on my
network.

Thanks to Steven and Niall also.

2015-10-27 4:47 GMT-04:30 Simon Hobson <dhcp1 at thehobsons.co.uk>:

> Steven Carr <sjcarr at gmail.com> wrote:
>
> > On 27 October 2015 at 04:18, Roberto De Oliveira <rcdeoliveira at gmail.com>
> 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
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>



-- 
Saludos,
Roberto De Oliveira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20151028/24f5fa84/attachment.html>