Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: isc-dhcp 4.4.2-p1 shared-network confusion (Simon)
2. Re: isc-dhcp 4.4.2-p1 shared-network confusion (Philippe Maechler)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Jul 2022 21:56:47 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: isc-dhcp 4.4.2-p1 shared-network confusion
Message-ID: <7172b7a9-6e19-49e0-80af-04df97afb...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Philippe Maechler <plcmaech...@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
------------------------------
Message: 2
Date: Thu, 7 Jul 2022 06:55:29 +0200
From: Philippe Maechler <plcmaech...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: isc-dhcp 4.4.2-p1 shared-network confusion
Message-ID:
<caphukga7j22blexkamuz3hmbkko2ypapeg732xmk0yclfoa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <dh...@thehobsons.co.uk> wrote:
> Philippe Maechler <plcmaech...@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
>
> --
> 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
> dhcp-users@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/20220707/ae981506/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
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
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 165, Issue 4
******************************************
