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. Compiling ISC DHCP without bind library. (Venkatesh Siddappa)
2. Re: Weird behavior with multiple pool inside shared networks
(Roberto De Oliveira)
3. RE: Weird behavior with multiple pool inside shared networks
(Patrick Trapp)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Oct 2015 14:04:55 +0000
From: Venkatesh Siddappa <[email protected]>
To: "Users of ISC DHCP ([email protected])"
<[email protected]>
Subject: Compiling ISC DHCP without bind library.
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
I have limited memory in my box, where I just need the dhcp functionlity (not
needed dns or ddns or related anything to DNS and bind => as bind9 memory usage
will be high).
Is their any standard way available in latest dhcp package with compile time
flags or any work arounds to not to link bindlib(esapecially libdns.a).
Problem is that all dhcp process(total 6 (clientv4/v6,servev4/v6r,relayv4/v6
taking huge memory in box).
Or please let me know if dhcp and bind are tightly coupled, so no way to
saparate easily. (unleass some hacky solutions => non statndard)
Or some thing I am thinking is not a better method for use case of ISC-DHCP.
so please let me know yout thoughts.
Thanks in Advance.
Regards,
Venkaesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151028/eda14b94/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 28 Oct 2015 09:59:45 -0430
From: Roberto De Oliveira <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Weird behavior with multiple pool inside shared networks
Message-ID:
<cagyousvl53ycoh+c6otedcqlov0qk3pxi_ta1uebq0hwz4d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]>:
> 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.
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
--
Saludos,
Roberto De Oliveira
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151028/24f5fa84/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 28 Oct 2015 14:49:17 +0000
From: Patrick Trapp <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: RE: Weird behavior with multiple pool inside shared networks
Message-ID:
<1d507d610594d14f86d40d77c17e9e6626409...@exchangedsb.ruralnex.com>
Content-Type: text/plain; charset="iso-8859-1"
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: [email protected] [[email protected]] on
behalf of Roberto De Oliveira [[email protected]]
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
<[email protected]<mailto:[email protected]>>:
Steven Carr <[email protected]<mailto:[email protected]>> wrote:
> On 27 October 2015 at 04:18, Roberto De Oliveira
> <[email protected]<mailto:[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.
_______________________________________________
dhcp-users mailing list
[email protected]<mailto:[email protected]>
https://lists.isc.org/mailman/listinfo/dhcp-users
--
Saludos,
Roberto De Oliveira
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151028/76e714dc/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 84, Issue 24
******************************************
