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. IP Pools with preference/priority on ISC DHCP Server
(Muhammad Faisal)
2. Re: IP Pools with preference/priority on ISC DHCP Server
(Simon Hobson)
3. Re: [Bug Report] key conflict message for create host by
Omapi (Simon Hobson)
4. Re: Weird behavior with multiple pool inside shared networks
(Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Oct 2015 05:58:09 +0000 (UTC)
From: Muhammad Faisal <[email protected]>
To: "[email protected]" <[email protected]>
Subject: IP Pools with preference/priority on ISC DHCP Server
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Experts,
Is there any way we can define two pools for a subnet or a shared network with
preference. The scenario is we have two pools we want first pool to be used but
in case of spill over another defined pool to be used. How we can set the
priority??Regards, Muhammad Faisal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151029/9a802bb0/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 29 Oct 2015 11:38:11 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: IP Pools with preference/priority on ISC DHCP Server
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Muhammad Faisal <[email protected]> wrote:
> Is there any way we can define two pools for a subnet or a shared network
> with preference. The scenario is we have two pools we want first pool to be
> used but in case of spill over another defined pool to be used. How we can
> set the priority?
That isn't supported.
All pools have equal priority* and are considered equivalent (as in, any client
can have any available address) unless allow/deny statements say otherwise.
* The only exception to that is while there are "never used" addresses in which
case these will be given to new clients in an order defined by the way the code
happens to work. At present this is "top down" (highest numerical value first)
but that is undocumented, undefined, and liable to change without notice.
There is one way round this that I can think of, and that's to "fiddle with the
leases". It's messy but it would achieve what you want.
Monitor the pool you want to have priority, and as long as there are currently
free addresses in there then do one of :
1) Set a small number of them to "never used" - ie delete them.
If the "top down" allocation order suits you (ie the priority pool is
numerically higher than the other pool), then any new clients coming along will
get one of those "never used" addresses. You will also need to delete any
leases in the second pool as they expire - otherwise those clients will always
get the same address.
2) Fiddle with the leases so that the "least recently used" algorithm will
always pick an address from the priority pool - eg set the expired time a long
time in the past. You will also need to maintain dummy leases in the second
pool so that those addresses always come last in the "least recently used"
calculation.
Option 2 is probably easiest. You could create dummy leases for all addresses
you want to be lower priority, and keep adjusting the expired time to be very
recent so that expired leases in the priority pool will get used in preference.
You'll also need to remove any real leases in the second pool when they expire
(as long as there are spare address in the first pool) so that clients will
switch back to the priority pool when they come back.
But really, it's a lot of work and hassle - and for what ?
Either the addresses in the second pool "work" - in which case, what's wrong
with using them. Or they don't "work" - in which case you have a bigger problem.
Perhaps if you explained what the requirements are, rather than how you think
you want to achieve it, there might be other ideas.
------------------------------
Message: 3
Date: Thu, 29 Oct 2015 11:47:26 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: [Bug Report] key conflict message for create host by
Omapi
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Muhammad Faisal <[email protected]> wrote:
> The DHCP experts might explain this but what about arp resolution within the
> server ? The MAC address is a unique identifier so if your deployment is
> getting two IP for the same MAC how the conflict will resolve?
The assumption is that the client won't be in two places at once - so wherever
it is located at any point in time, ARP will work fine and there's no conflict.
However, a device with a single MAC address can have two IP addresses - and
that'll work fine. Also, though I *REALLY* do not recommend this, you can have
two clients with the same MAC address in different networks (in different
collision domains) and IP addressing will work fine - ARP resolution within
each network will work fine, the MAC address only needs to be unique within one
collision domain*.
As far as the DHCP server is concerned, it'll quite happily lease different
addresses to the "same client" in different networks. You can see this if you
(for example) plug a computer into one network, let it get an address, then
pull the network cable (so it can't release the lease). When you plug it into
another network, it'll get another address - but the first lease is still
current.
* Amusing story.
Our local LUG used to meet in a university facility. They bought a truckload of
new computers, and had "strange" network problems with a few computers.
Eventually they pinned it down to MAC addresses - the manufacturer had a bug in
their addressing code, and duplicated one address in every 257 machines ! This
hadn't shown up before since it is only a problem if those 2 machines in each
set of 257 are on the same network - and even buying 300+ machines wouldn't
guarantee that you got consecutive MAC addresses.
------------------------------
Message: 4
Date: Thu, 29 Oct 2015 11:52:57 +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
Muhammad Faisal <[email protected]> wrote:
> Recently encountered the situation where different clients are required to be
> segregated for different cities and assigned different subnets from
> centralized server. For this we have defined required subnets and used
> "option router" to classify different hosts for respective subnet. Using
> shared network to achieve the above did not work as explained below.
I assume these different cities were using different subnets, with traffic
routed between them ? If so then that is *NOT* a shared network, and you are
correct that defining a shared-network would not work. For multiple routed
networks, selecting an appropriate address for the client happens automagically
based on the GI-Addr (Gateway Interface Address) value inserted into the
relayed packet by the BOOTP relay agent serving the remote network.
BTW - for an easy to read and in depth explanation of how it all works, lookup
The DHCP Handbook by Ralph Droms and Ted Lemon (two of the key people
responsible for the ISC DHCP server, and who really know their stuff). I
recommend this book - it covers the "why" (including an explanation of earlier
methods), and the "how". The 2nd edition also covers failover.
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 84, Issue 27
******************************************
