Re: isc-dhcp 4.4.2-p1 shared-network confusion

Thanks again Simon

It's always nice to read and learn from your replies

Probably one last question:
> > The key part of my question is:
> > > The relay agent then sends the modified packet, typically via
unicast, to the server address(es) it’s been configured with.
> > > Based on the  GI-Addr, the server picks a suitable subnet/shared
network and then applies any rules (such as allow statements in pools) in
order to pick an address to offer the client.
> >
> > How will the GI-Addr have an impact on the pool selection?
> > In my example the two shared networks (abc and xyz) are equal. Are they
also equal to the subnets 6.6.6.0/24 and 7.7.7.0/24 ?
>
> Yes, but ...
> If (say) the GI-Addr is 20.1.0.1 then ONLY shared-network xyz is a
candidate. The other subnets and shared-networks are irrelevant as the
GI-Addr is not within any of them. It’s as simple as that.

What if the GI-Addr is something completely different like 140.1.0.1?

/BR
Philippe


On Wed, 6 Jul 2022 at 22:57, Simon <[email protected]> wrote:

> Philippe Maechler <[email protected]> wrote:
>
> > The key part of my question is:
> > > The relay agent then sends the modified packet, typically via unicast,
> to the server address(es) it’s been configured with.
> > > Based on the  GI-Addr, the server picks a suitable subnet/shared
> network and then applies any rules (such as allow statements in pools) in
> order to pick an address to offer the client.
> >
> > How will the GI-Addr have an impact on the pool selection?
> > In my example the two shared networks (abc and xyz) are equal. Are they
> also equal to the subnets 6.6.6.0/24 and 7.7.7.0/24 ?
>
> Yes, but ...
> If (say) the GI-Addr is 20.1.0.1 then ONLY shared-network xyz is a
> candidate. The other subnets and shared-networks are irrelevant as the
> GI-Addr is not within any of them. It’s as simple as that.
>
> > Did I got this right? The server picks a suitable subnet/shared-network
> (which in my case can be from anything from the defined subnets with a
> pool) and then applies the allow- and deny rules?
>
> Where “suitable” means valid for where the client is located.
> The key is that address selection is tightly bound to client location -
> only pools/ranges applicable to the network segment to which the client is
> connected will be considered.
>
> Taking a step back, if a client was connected to the network where the
> server has address 4.4.4.10, then ONLY addresses in that subnet could be
> considered. Since there are none, there would be no suitable addresses and
> the client wouldn’t be left wanting.
> In your case, the clients are on “remote” networks and rely on relay
> agents. Again, for each network, the server will ignore all other network
> than the one for which the GI-Addr is valid.
>
> So in the basic case, you need do absolutely nothing beyond accurately
> defining your subnets and shared networks - each client will automagically
> get an address that is appropriate to the network to which you connect it.
> And if you move a client to a different network, it will be given a
> different address appropriate to that new location.
>
> > I guess, when a deny rule applies, the server will just pick the next
> subnet/shared-network, applies the rules and so on until there is either an
> allow-case or there are no subnet/shared networks left
> > (For simplicity we ignore that there can be full pools :) )
>
> No, it’s actually nothing at all like that !
> Firstly, as above, only addresses valid for the network location will be
> considered - this is automagic and you don’t have to do anything for it to
> work (other than correctly define your DHCP config to match the network).
>
> Then allow and deny do NOT work as most people would expect. It’s
> complicated, but they are not applied in order like in many systems and the
> simplest advice is “never mix allow and deny in one pool". Be aware that
> whenever you use allow or deny, there is then an implicit “deny anything
> not explicitly allowed” or “allow anything not explicitly denied”. It can
> get a bit messy as you can end up with something like :
> pool {
>   allow members of “a”;
>   # There’s an implicit deny anything not in “a” here
> }
> pool {
>   allow members of “b”;
>   # There’s an implicit deny anything not in “b” here
> }
> Pool {
>   deny members of “a”;
>   deny members of “b”;
>   # There’s an implicit allow anything not in “a” or “b” here
> }
> which will give you a pool for members of a, a pool for members of b, and
> a pool for everything else. Note that just because a client is allowed in
> one pool, it does not automatically exclude it from any other pool. And
> it’s valid for a client to be a member of more than one class.
>
> So now we come to how an address is allocated from those which are valid
> for the network and permitted by any allow/deny statements.
> Firstly, if the client has an existing lease, no matter how long ago it
> might have expired, and the current rules permit the use of that address -
> then that address will be offered.
> Next, if there are any “never used” addresses, then one of those is
> chosen. “never used” here means that there is no lease record at all in the
> server history - i.e. no matter how far back you go, it has never been used
> before. Of these, due to the internal hash-table implementation (which is
> not documented and liable to change at any time without warning - so don’t
> rely on it) they are chosen in a top-down manner - i.e. 10.2.1.123 would be
> chosen before 10.1.1.234.
> If you’ve had a bit of client churn over the life of the server and there
> are no such “never used” addresses, then a free address is chosen on a
> least recently used basis - i.e. whichever has been expired for the longest
> time.
> If there are none of these, then any abandoned leases are considered and
> one will be recovered and re-used. Addresses are labelled as abandoned if
> the server detects that what should be a free address is actually in use
> (using it’s "ping before offer” safety net).
> And if you get here - there’s nothing available, the server will log “no
> free leases”, and no offer will be made to the client.
>
>
> Hopefully that clears up your confusion :-)
>
> Simon
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

-- 
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

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