isc-dhcp 4.4.2-p1 shared-network confusion

[Simon]

Philippe Maechler <plcmaechler at gmail.com> 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