Send dhcp-users mailing list submissions to
[email protected]
Advertising
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Weird behavior with multiple pool inside shared networks
(Steven Carr)
2. Re: Weird behavior with multiple pool inside shared networks
(Simon Hobson)
3. classes for hostnames (Andreas Burger)
4. Re: Weird behavior with multiple pool inside shared networks
(Niall O'Reilly)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Oct 2015 08:16:34 +0000
From: Steven Carr <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Weird behavior with multiple pool inside shared networks
Message-ID:
<CALMep0691MkQuG7iatQ7hVFeTZuojyyC9=iwn+zchgq9t1h...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 27 October 2015 at 04:18, Roberto De Oliveira <[email protected]> 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.
Steve
------------------------------
Message: 2
Date: Tue, 27 Oct 2015 09:17:59 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Weird behavior with multiple pool inside shared networks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Steven Carr <[email protected]> wrote:
> On 27 October 2015 at 04:18, Roberto De Oliveira <[email protected]>
> 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.
------------------------------
Message: 3
Date: Tue, 27 Oct 2015 11:01:09 +0100
From: Andreas Burger <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: classes for hostnames
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
hi there,
we define hosts with dedicated ip-adresses based on the mac.
and we have pools where known-clients are allowed.
to have them online, when tehy are in an other of our nets.
what i would like to do, is define classes that are allowed/denyed for
some pools. but not baesd on mac, but on a regex of the hostname (or a
tag or so)
has someone done such things or has a hint, how to make that?
regards
andreas
--
________________________________________________
Andreas Burger
Eidgenoessische Technische Hochschule Zuerich
Departement Hest ISG
LFV E31 8092 Zuerich +41 44 632 68 54
[email protected]
_________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3943 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151027/5cce6056/attachment-0001.bin>
------------------------------
Message: 4
Date: Tue, 27 Oct 2015 10:14:44 +0000
From: "Niall O'Reilly" <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Weird behavior with multiple pool inside shared networks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On Tue, 27 Oct 2015 09:17:59 +0000,
Simon Hobson wrote:
>
> 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.
Absolutely.
It's also worth bearing in mind that the address shown in the "via"
phrase of the log message for DHCPDISCOVER is just arbitrarily
selected by the gateway/relay from the addresses configured on the
interface connected to the shared network. It may be the "primary"
address, or the one first in sort order, according to the
implementation. In particular, the example "via 186.90.0.1" doesn't
indicate anything which should prevent a DHCPOFFER from carrying an
address from the other subnet.
ATB
Niall
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 84, Issue 21
******************************************
