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. best practice for fixed-address / reserved leases
(Michael Schnyder)
2. Re: best practice for fixed-address / reserved leases
(Bill Shirley)
3. Re: best practice for fixed-address / reserved leases
(Simon Hobson)
4. Re: best practice for fixed-address / reserved leases
(Michael Schnyder)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Dec 2020 12:57:06 +0000
From: Michael Schnyder <mschny...@open-systems.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: best practice for fixed-address / reserved leases
Message-ID: <fb99777c-ff31-419b-99db-695fc2c08...@open-systems.com>
Content-Type: text/plain; charset="utf-8"
Hi
Need to have an answer for correct configuring / assigning fixed ip addresses:
We defined a while ago our "best practice" to configure a fixed address
definition outside the dhcp range:
-------------- example
subnet 172.1.2.0 netmask 255.255.255.0 {
range 172.1.2.10 172.1.2.50;
option routers 172.1.1.1;
default-lease-time 21600;
}
# Fixed Address 1
host abc {
hardware ethernet ab:c2:33:22:66:44;
fixed-address 172.1.2.51; ### <- ip is NOT within the range 172.1.2.10
172.1.2.50;
}
# Phone Fixed Address
host cde {
hardware ethernet cd:e2:33:22:66:44;
fixed-address 172.1.2.52; ### <- ip is NOT within the range 172.1.2.10
172.1.2.50;
}
------------- example end
For me it's unclear why we should define it like that and unfortunately, I
could not find yet an answer in the manual (also see [1]), therefore my
question:
Is it mandatory that a "fixed" ip address is part of the range?
Or is it mandatory that it is _explicitly not_ part of the defined range?
Or does it matter at all? Can I define within the subnet whatever ip address I
would like to?
[1] https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf#RESERVED%20LEASES
Thanks for your tipps.
Kind regards
michael
------------------------------
Message: 2
Date: Wed, 30 Dec 2020 14:00:06 -0500
From: Bill Shirley <b...@c3po.polymerindustries.biz>
To: dhcp-users@lists.isc.org
Subject: Re: best practice for fixed-address / reserved leases
Message-ID:
<46a40255-a7fc-6043-b229-bb48408b0...@c3po.polymerindustries.biz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Fixed addresses should NOT be in any range.? It's possible for DHCP to assign
that address
before the device with that fixed address gets it.
BTW, your subnet and addresses are not in the RFC 1918 range.
https://tools.ietf.org/html/rfc1918
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
You are using public addresses on your private network.
Bill
On 12/30/2020 7:57 AM, Michael Schnyder wrote:
> Hi
>
> Need to have an answer for correct configuring / assigning fixed ip addresses:
>
> We defined a while ago our "best practice" to configure a fixed address
> definition outside the dhcp range:
>
> -------------- example
> subnet 172.1.2.0 netmask 255.255.255.0 {
> range 172.1.2.10 172.1.2.50;
> option routers 172.1.1.1;
> default-lease-time 21600;
> }
> # Fixed Address 1
> host abc {
> hardware ethernet ab:c2:33:22:66:44;
> fixed-address 172.1.2.51; ### <- ip is NOT within the range 172.1.2.10
> 172.1.2.50;
> }
> # Phone Fixed Address
> host cde {
> hardware ethernet cd:e2:33:22:66:44;
> fixed-address 172.1.2.52; ### <- ip is NOT within the range 172.1.2.10
> 172.1.2.50;
> }
> ------------- example end
>
> For me it's unclear why we should define it like that and unfortunately, I
> could not find yet an answer in the manual (also see [1]), therefore my
> question:
>
> Is it mandatory that a "fixed" ip address is part of the range?
> Or is it mandatory that it is _explicitly not_ part of the defined range?
> Or does it matter at all? Can I define within the subnet whatever ip address
> I would like to?
>
>
> [1]
> https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf#RESERVED%20LEASES
>
> Thanks for your tipps.
>
> Kind regards
> michael
>
> _______________________________________________
> 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/20201230/e8e6cd17/attachment-0001.htm>
------------------------------
Message: 3
Date: Wed, 30 Dec 2020 21:21:50 +0000
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: best practice for fixed-address / reserved leases
Message-ID: <19819333-b12c-477c-b8ec-9a0a8f951...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Bill Shirley <b...@c3po.polymerindustries.biz> wrote:
> Fixed addresses should NOT be in any range. It's possible for DHCP to assign
> that address
> before the device with that fixed address gets it.
To expand on that a bit ...
The ISC server (and I'm talking dhcpd here, not Kea which I'm not familiar
with) is very different to the Windows service many people are familiar with.
With the Windows service, your fixed addresses are part of the range (which is
usually defined as the whole of the usable subnet with sections reserved so
they aren't used). With the ISC server the fixed addresses are treated somewhat
differently to dynamic clients and the server makes no attempt whatsoever to
exclude them from the dynamic ranges - so as Bill says, it's entirely possible
for a dynamic client to be given the address.
But you may be thinking that this would be hard to do - after all, the fixed
address device has it leased to it doesn't it ? Well no it doesn't - the ISC
server does not track address status for fixed address assignments - in theory
it doesn't need to. Simply put, the admin has said that there's a one-one
mapping between that address and a device - so it can only ever be leased to
that device, and it really doesn't matter about keeping lease state for it. So
there is no lease record kept - the server just bypasses all of that.
So when a dynamic client comes along for a lease, and according to whatever
rules are in place (more on that later), that fixed address happens to be the
one selected for the dynamic client - then it will be selected. If the fixed
address devices is offline at the time OR it is configured to not respond to
pings OR the server is configured not to do it's "ping before offer" check -
then the address will be leased to the client and you now have an address
collision. That "ping before offer" is your safety net in these cases, it
defaults to on, and if the device is both online and replies to a ping, then
the server will flag the dynamic lease as abandoned and it won't be offered to
anything again (except the fixed address device) unless there really is nothing
left to offer.
Now, about that address selection policy ?
Here is another big difference from the Windows service. From memory, the
Windows service tends to allocate addresses from the bottom of the available
pool - and will happily re-allocate an address when it's not in use. So if you
have a fixed address high up in the range, it may be a long time (or even
never) before your dynamic assignments get up to it. In the Windows world, a
lot of what is supposed to happen at the server end according to the RFCs is
actually fudged by making the clients very clingy to their previously leased
address.
With the ISC server, dynamic address assignment is done very differently, and
follows these rules - always following any allow/deny conditions attached to a
pool. The address offered will be the first found of :
1) A previously never used address - working (as an undocumented and not
guaranteed to not change without warning implementation detail) top-down in a
list of all addresses available to be given to the client.
2) If there are no "never used" addresses, then a free lease (i.e. one that's
expired or been released by the client) working on a least recently used basis.
Under normal operations, these will be the only cases used. By default, the
server will ping an address before it offers it to the client - if it gets a
reply then it will mark the lease as abandoned, after which it will never get
selected again unless ...
3) If there are no free leases to be offered, but there are abandoned ones,
then it will try one of the abandoned ones - if it gets no reply to a ping then
it will change it to free and then offer it to the client as in 2) above.
There's also something about leases made to bootp clients. IIRC, because bootp
doesn't have a concept of lease time, all such leases are infinite and can't be
re-allocated.
Reading the above, you can probably see why most people have no problem most of
the time - to the extent that I've seen some "rather poor" advice in the past.
In one case I recall, someone offered a script that monitored the dhcp logs,
detected when you plugged in an IP phone, then added a fixed-IP statement
(within a host record) for that device to the dhcp config, and configured the
IP PBX to use the new device. I had a discussion with the author of the script
who declared "so ping will fix it, no problem, nothing to fix".
IFF ping before offer is left on AND the device responds to pings AND it is
online when it's address first gets picked for a dynamic clients - THEN the
address will be abandoned, and IFF you never run out of free addresses then you
won't have a problem.
MOST of the time that will be the case, but it's not 100% guaranteed to work,
and when it doesn't then you can get some "interesting" issues.
So there's the detail as to why you should NEVER configure a fixed-address that
is within a dynamic range. Stick to that rule and you won't have a problem with
it, break it and you probably won't have a problem - but when you do it'll be a
long time down the road and cause you some head scratching.
For completeness, you may have spotted a little detail implied by the "bypasses
the normal lease processing" bit above. That also means there are no DNS
updates done for fixed-addresses - you'd normally manually configure the DNS,
and you can use a DNS name in place of the IP address in the DHCP config. You
can configure the server to do DNS updates for fixed-addresses - but then it
will blindly do them EVERY time a fixed address requests or renews a lease
(performance issue), and it will never remove them (you'll have to manually
remove them).
BTW - there is an alternative to fixed-addresses. If you create a skeleton
lease (which must be within a range) and mark it as reserved, or add a line to
an existing lease record, then that lease will be reserved to that client. In
practical terms, this means the lease goes through the normal lease cycles
including adding/removing the DNS records as the lease becomes active or free.
The only difference is that when in the free state, the address cannot be
re-allocated to another client.
You can either manually edit the leases file while the server is shut down, or
I believe it can be done via OMAPI.
On the upside, such reserved addresses work the same way as dynamic addresses,
just with the address being tied to a client in the same way as "fixed-address"
does. And they can be within a dynamic range - making it easy to plug a device
in, see what address it gets, and simply mark that lease as reserved.
On the downside, they don't appear anywhere in the config - the only place to
see them is in the leases database (or with tools that will parse the leases
database for you).
A dynamic lease configured as "reserved" is much closer in operation to the
reserved addresses in the Windows DHCP service.
Simon
------------------------------
Message: 4
Date: Thu, 31 Dec 2020 00:31:41 +0000
From: Michael Schnyder <mschny...@open-systems.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: best practice for fixed-address / reserved leases
Message-ID: <7625c527-9a95-4765-90fe-9f20dea62...@open-systems.com>
Content-Type: text/plain; charset="utf-8"
Bill, Simon: Many thanks for the answers, both: The short and the long version!
I'm glad to read all that and it helps to explain why we use that "best
practice". It's perfect to also get a better understanding of the difference
between the ISC server and the Windows service, as exactly that is to be
explained most of the time.
PS: Good that you mentioned it, Bill: This was a really bad example with subnet
and addresses not being part of the RFC 1918 range. Please: Do not copy/paste
this example into your environment. I just wrote down some "numbers" (even with
a mistake). Important to me was to show that the fixed-address is outside the
defined range.
Very much appreciated,
Michael
?On 30.12.20, 22:22, "dhcp-users on behalf of Simon Hobson"
<dhcp-users-boun...@lists.isc.org on behalf of dh...@thehobsons.co.uk> wrote:
Bill Shirley <b...@c3po.polymerindustries.biz> wrote:
> Fixed addresses should NOT be in any range. It's possible for DHCP to
assign that address
> before the device with that fixed address gets it.
To expand on that a bit ...
The ISC server (and I'm talking dhcpd here, not Kea which I'm not familiar
with) is very different to the Windows service many people are familiar with.
With the Windows service, your fixed addresses are part of the range (which is
usually defined as the whole of the usable subnet with sections reserved so
they aren't used). With the ISC server the fixed addresses are treated somewhat
differently to dynamic clients and the server makes no attempt whatsoever to
exclude them from the dynamic ranges - so as Bill says, it's entirely possible
for a dynamic client to be given the address.
But you may be thinking that this would be hard to do - after all, the
fixed address device has it leased to it doesn't it ? Well no it doesn't - the
ISC server does not track address status for fixed address assignments - in
theory it doesn't need to. Simply put, the admin has said that there's a
one-one mapping between that address and a device - so it can only ever be
leased to that device, and it really doesn't matter about keeping lease state
for it. So there is no lease record kept - the server just bypasses all of that.
So when a dynamic client comes along for a lease, and according to whatever
rules are in place (more on that later), that fixed address happens to be the
one selected for the dynamic client - then it will be selected. If the fixed
address devices is offline at the time OR it is configured to not respond to
pings OR the server is configured not to do it's "ping before offer" check -
then the address will be leased to the client and you now have an address
collision. That "ping before offer" is your safety net in these cases, it
defaults to on, and if the device is both online and replies to a ping, then
the server will flag the dynamic lease as abandoned and it won't be offered to
anything again (except the fixed address device) unless there really is nothing
left to offer.
Now, about that address selection policy ?
Here is another big difference from the Windows service. From memory, the
Windows service tends to allocate addresses from the bottom of the available
pool - and will happily re-allocate an address when it's not in use. So if you
have a fixed address high up in the range, it may be a long time (or even
never) before your dynamic assignments get up to it. In the Windows world, a
lot of what is supposed to happen at the server end according to the RFCs is
actually fudged by making the clients very clingy to their previously leased
address.
With the ISC server, dynamic address assignment is done very differently,
and follows these rules - always following any allow/deny conditions attached
to a pool. The address offered will be the first found of :
1) A previously never used address - working (as an undocumented and not
guaranteed to not change without warning implementation detail) top-down in a
list of all addresses available to be given to the client.
2) If there are no "never used" addresses, then a free lease (i.e. one
that's expired or been released by the client) working on a least recently used
basis.
Under normal operations, these will be the only cases used. By default, the
server will ping an address before it offers it to the client - if it gets a
reply then it will mark the lease as abandoned, after which it will never get
selected again unless ...
3) If there are no free leases to be offered, but there are abandoned ones,
then it will try one of the abandoned ones - if it gets no reply to a ping then
it will change it to free and then offer it to the client as in 2) above.
There's also something about leases made to bootp clients. IIRC, because
bootp doesn't have a concept of lease time, all such leases are infinite and
can't be re-allocated.
Reading the above, you can probably see why most people have no problem
most of the time - to the extent that I've seen some "rather poor" advice in
the past. In one case I recall, someone offered a script that monitored the
dhcp logs, detected when you plugged in an IP phone, then added a fixed-IP
statement (within a host record) for that device to the dhcp config, and
configured the IP PBX to use the new device. I had a discussion with the author
of the script who declared "so ping will fix it, no problem, nothing to fix".
IFF ping before offer is left on AND the device responds to pings AND it is
online when it's address first gets picked for a dynamic clients - THEN the
address will be abandoned, and IFF you never run out of free addresses then you
won't have a problem.
MOST of the time that will be the case, but it's not 100% guaranteed to
work, and when it doesn't then you can get some "interesting" issues.
So there's the detail as to why you should NEVER configure a fixed-address
that is within a dynamic range. Stick to that rule and you won't have a problem
with it, break it and you probably won't have a problem - but when you do it'll
be a long time down the road and cause you some head scratching.
For completeness, you may have spotted a little detail implied by the
"bypasses the normal lease processing" bit above. That also means there are no
DNS updates done for fixed-addresses - you'd normally manually configure the
DNS, and you can use a DNS name in place of the IP address in the DHCP config.
You can configure the server to do DNS updates for fixed-addresses - but then
it will blindly do them EVERY time a fixed address requests or renews a lease
(performance issue), and it will never remove them (you'll have to manually
remove them).
BTW - there is an alternative to fixed-addresses. If you create a skeleton
lease (which must be within a range) and mark it as reserved, or add a line to
an existing lease record, then that lease will be reserved to that client. In
practical terms, this means the lease goes through the normal lease cycles
including adding/removing the DNS records as the lease becomes active or free.
The only difference is that when in the free state, the address cannot be
re-allocated to another client.
You can either manually edit the leases file while the server is shut down,
or I believe it can be done via OMAPI.
On the upside, such reserved addresses work the same way as dynamic
addresses, just with the address being tied to a client in the same way as
"fixed-address" does. And they can be within a dynamic range - making it easy
to plug a device in, see what address it gets, and simply mark that lease as
reserved.
On the downside, they don't appear anywhere in the config - the only place
to see them is in the leases database (or with tools that will parse the leases
database for you).
A dynamic lease configured as "reserved" is much closer in operation to the
reserved addresses in the Windows DHCP service.
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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5898 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20201231/acc3ad6a/attachment.bin>
------------------------------
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 146, Issue 15
*******************************************
