Weird behavior with multiple pool inside shared networks

Thu Oct 29 05:42:20 UTC 2015

Few cents of mine:
Recently encountered the situation where different clients are required to be segregated for different cities and assigned different subnets from centralized server. For this we have defined required subnets and used "option router" to classify different hosts for respective subnet. Using shared network to achieve the above did not work as explained below. Regards, Muhammad Faisal.

      From: Patrick Trapp <ptrapp at nex-tech.com>
 To: Users of ISC DHCP <dhcp-users at lists.isc.org> 
 Sent: Wednesday, October 28, 2015 7:49 PM
 Subject: RE: Weird behavior with multiple pool inside shared networks

#yiv8026376269 P {margin-top:0;margin-bottom:0;}I meant to reply earlier. I have nothing to add to the excellent responses you already have in hand, but we are doing what you are trying to do, I think, by using option-82 information to determine the source network of the request and assigning to the desired pool accordingly.

I'm sure there are other ways, but I thought I would share that one since I know it works for our equipment and our network.

From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Roberto De Oliveira [rcdeoliveira at gmail.com]
Sent: Wednesday, October 28, 2015 9:29 AM
To: Users of ISC DHCP
Subject: Re: Weird behavior with multiple pool inside shared networks

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
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20151029/06c1c0a1/attachment.html>