best practice for fixed-address / reserved leases

[Michael Schnyder]

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Bill Shirley <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Michael Schnyder]

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" <[hidden email] on behalf of [hidden email]> wrote:

    Bill Shirley <[hidden email]> 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
    [hidden email]
    https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[glenn.satchell]

Hi Michael,

One other alternative to a reserved lease (which is essentially infinite
time) could be to set a very long lease, say a few months or 1 year -
just make it a longer than any amount of time the system might be not on
the network.

This can be done in dhcpd.conf, in this case a dynamic address from the
pool is assigned. If there were a few of these they could be put in a
group{} or a class.

host foo {
   hardware ethernet aa:bb:cc:dd:ee:ff;
   # 1 year in seconds
   min-lease-time 31536000;
}

class "long" {
   match pick-first-value (option dhcp-client-identifier, hardware);
   min-lease-time 31536000;
}
subclass "long" 1:aa:bb:cc:dd:ee:ff; # repeat for more devices

The other advantage here is that if the device is permanently removed
from the network, eventually the lease will expire and be available for
re-use by other systems.

regards,
Glenn

On 2020-12-31 11:31, Michael Schnyder wrote:

> 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"
> <[hidden email] on behalf of [hidden email]>
> wrote:
>
>     Bill Shirley <[hidden email]> 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
>     [hidden email]
>     https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

[hidden email] wrote:

> One other alternative to a reserved lease (which is essentially infinite time) could be to set a very long lease, say a few months or 1 year - just make it a longer than any amount of time the system might be not on the network.

...

> The other advantage here is that if the device is permanently removed from the network, eventually the lease will expire and be available for re-use by other systems.

That's a neat idea, never thought of that.

But if a client releases it's lease (e.g. on shutdown), doesn't that break the idea by setting the lease to free ? Or does it retain it's "year in the future" end time and thus go a long way down the list of leases when it comes to finding a free one for a new client ?

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Hi All,

Apologies if this is an obvious one but I'm new to using classes with isc-dhcpd.

I'm trying to set up a class to match some dev boards I am working with.

I'm trying to match on the "vendor-class-identifier" option but it's either not working or it's not working as I expected. 

I've created a lab setup with a RaspberryPi as my server for the testing,

For the test setup I'm calling dhcpd from the cli directly and keeping it in the foreground so I can see the output and this makes restarting it quick for this job.

The dev boards use bootp for their boot process the only option I need to set for them is the next-server.

So I created a class as you can see below which matches on the vendor-class-identifier which I've confirmed is being sent.

But the board never gets the next-server from the class and I never see the log line on the console.

If I please the next server and log line in the subnet it works as expected.

Looking in the lease file I see the vendor-class-identifier is set as expected by the board.

I've had to scrub the mac address of the board so it's just replaced with a placeholder.

Can anyone please advise am I missing something or is my understanding of classes incorrect (This is very possible)

Thanks for your time

Cheers

Mark

# dhcpd --version
isc-dhcpd-4.4.1


dhcpd.conf
option domain-name "example.org";
option domain-name-servers 8.8.8.8;
default-lease-time 600;
max-lease-time 7200;
allow booting;
allow bootp;
ddns-update-style none;
authoritative;
subnet 192.168.20.0 netmask 255.255.255.0 {
  range dynamic-bootp 192.168.20.100 192.168.20.150;
  option domain-name-servers 198.18.198.18;
  option domain-name "blah.domain.ie.";
  option routers 192.168.20.1;
  default-lease-time 300;
  max-lease-time 300;
}

class "Devboot"{
        match if option vendor-class-identifier = "Mips_boot";
        next-server 192.168.20.10;
        log (info,"Devboot");
}

Console Output

root@server:/etc/dhcp# dhcpd -4 -f -d -cf /etc/dhcp/dhcpd.conf eth0
Internet Systems Consortium DHCP Server 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Config file: /etc/dhcp/dhcpd.conf
Database file: /var/lib/dhcp/dhcpd.leases
PID file: /var/run/dhcpd.pid
Wrote 0 class decls to leases file.
Wrote 0 leases to leases file.
Listening on LPF/eth0/dc:a6:32:5a:2c:24/192.168.20.0/24
Sending on   LPF/eth0/dc:a6:32:5a:2c:24/192.168.20.0/24
Sending on   Socket/fallback/fallback-net
Server starting service.

BOOTREQUEST from AA:BB:CC:DD:EE:FF via eth0
BOOTREPLY on 192.168.20.100 to AA:BB:CC:DD:EE:FF via eth0


dhcpd.leases
lease 192.168.20.100 {
  starts 1 2021/01/04 22:35:33;
  ends never;
  cltt 1 2021/01/04 22:35:33;
  binding state active;
  next binding state free;
  rewind binding state free;
  dynamic-bootp;
  hardware ethernet AA:BB:CC:DD:EE:FF;
  set vendor-class-identifier = "Mips_boot";

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Mark Mc Nicholas <[hidden email]> wrote:

> class "Devboot"{
>         match if option vendor-class-identifier = "Mips_boot";
>         next-server 192.168.20.10;
>         log (info,"Devboot");
> }

Is it "option vendor-class-identifier" or just "vendor-class-identifier" ?
I'm a bit rusty, and TBH never really used classes much anyway, but I vaguely recall that "option vendor-class-identifier" would be the option value set by the server, while "vendor-class-identifier" would match the field in the incoming packet.

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Hey Simon,

Thanks for the suggestion,

I've just tried a very quick check changing the match statement to " match if vendor-class-identifier = "Mips_boot";"

however from a very quick glance the result looked the same as the device didn't boot and I saw no log lines "Devboot" on the console.

I will do a more detailed check this evening. I still welcome input from other users please

Cheers

Mark

On Tue, Jan 5, 2021 at 11:50 AM Simon Hobson <[hidden email]> wrote:

Mark Mc Nicholas <[hidden email]> wrote:

> class "Devboot"{
>         match if option vendor-class-identifier = "Mips_boot";
>         next-server 192.168.20.10;
>         log (info,"Devboot");
> }

Is it "option vendor-class-identifier" or just "vendor-class-identifier" ?
I'm a bit rusty, and TBH never really used classes much anyway, but I vaguely recall that "option vendor-class-identifier" would be the option value set by the server, while "vendor-class-identifier" would match the field in the incoming packet.

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Mark Mc Nicholas <[hidden email]> wrote:
>
> Hey Simon,
> Thanks for the suggestion,
> I've just tried a very quick check changing the match statement to " match if vendor-class-identifier = "Mips_boot";"
> however from a very quick glance the result looked the same as the device didn't boot and I saw no log lines "Devboot" on the console.

One other thing to check is EXACTLY what the value is that you are testing for - in particular, look at a hex dump of the packet (or a decoded version of it). I've been caught out with things like trailing nulls, so it's 6 bytes of "value"0x00 not five bytes of "value" and the matching in dhcpd is very precise on this - they don't match.

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Markwalder]

Hi Mark:

I suspect Simon's hunch is correct, the vendor identifier may actually
be longer than "Mips_boot".  I just tried this configuration snippet and
it works fine:


class "Mips_boot" {
     match if (option vendor-class-identifier = "Mips_boot");
     next-server 192.168.20.10;
     log (info,"Devboot");
}

subnet 178.16.1.0 netmask 255.255.255.0 {
     pool {
         range 178.16.1.100 178.16.1.125;
     }
}

I get the log statement and the client gets next-server.   If there are
additional bytes after "Mips_boot" which you do not care about you can
use substr:

match if substring (option vendor-class-identifier, 0, 9) = "Mips_boot";




On 1/5/21 7:22 AM, Simon Hobson wrote:

> Mark Mc Nicholas <[hidden email]> wrote:
>> Hey Simon,
>> Thanks for the suggestion,
>> I've just tried a very quick check changing the match statement to " match if vendor-class-identifier = "Mips_boot";"
>> however from a very quick glance the result looked the same as the device didn't boot and I saw no log lines "Devboot" on the console.
> One other thing to check is EXACTLY what the value is that you are testing for - in particular, look at a hex dump of the packet (or a decoded version of it). I've been caught out with things like trailing nulls, so it's 6 bytes of "value"0x00 not five bytes of "value" and the matching in dhcpd is very precise on this - they don't match.
>
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Hi Thomas,

Firstly thank you for testing that is a great help to know it's working :) and my expectation of seeing the log line is correct.

I've just tried match if substring (option vendor-class-identifier, 0, 9) = "Mips_boot"; and no joy

I then tried match if not (substring (option vendor-class-identifier, 0, 9) = "Mips_boot"); which if I'm correct means that all devices should go into this class (Which is fine on a test network)

but still it didn't work, I also tried match if not (option vendor-class-identifier = "Mips_boot"); with the same logic of all devices should go here.

However neither presented the next server or created the log line.

Using wireshark I took a look at the BOOTP request and the vendor-class-identifier length is listed as being 9 the entry in the lease file doesn't show anything other than the Mips_boot statement

Cheers

Mark

On Tue, Jan 5, 2021 at 12:33 PM Thomas Markwalder <[hidden email]> wrote:

Hi Mark:

I suspect Simon's hunch is correct, the vendor identifier may actually
be longer than "Mips_boot".  I just tried this configuration snippet and
it works fine:


class "Mips_boot" {
     match if (option vendor-class-identifier = "Mips_boot");
     next-server 192.168.20.10;
     log (info,"Devboot");
}

subnet 178.16.1.0 netmask 255.255.255.0 {
     pool {
         range 178.16.1.100 178.16.1.125;
     }
}

I get the log statement and the client gets next-server.   If there are
additional bytes after "Mips_boot" which you do not care about you can
use substr:

match if substring (option vendor-class-identifier, 0, 9) = "Mips_boot";




On 1/5/21 7:22 AM, Simon Hobson wrote:
> Mark Mc Nicholas <[hidden email]> wrote:
>> Hey Simon,
>> Thanks for the suggestion,
>> I've just tried a very quick check changing the match statement to " match if vendor-class-identifier = "Mips_boot";"
>> however from a very quick glance the result looked the same as the device didn't boot and I saw no log lines "Devboot" on the console.
> One other thing to check is EXACTLY what the value is that you are testing for - in particular, look at a hex dump of the packet (or a decoded version of it). I've been caught out with things like trailing nulls, so it's 6 bytes of "value"0x00 not five bytes of "value" and the matching in dhcpd is very precise on this - they don't match.
>
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Markwalder]

Hi:

The reason is works for me is that my client is DHCP client.  This my
server output:

"
:
Listening on LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   Socket/fallback/fallback-net
Server starting service.
Devboot
DHCPDISCOVER from 08:00:27:25:d3:f4 via enp0s10
DHCPOFFER on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
Devboot
DHCPREQUEST for 178.16.1.100 (178.16.1.30) from 08:00:27:25:d3:f4 via
enp0s10
DHCPACK on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
"

Your's appears to be a BOOTP client.  BOOTP packets do not go through
classification.



_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Thank you Thomas for the clarification,

I've just finished testing with a DHCP client when I saw your mail come in and my results match. So is it possible to get BOOTP packets to go through classification or am I outta luck on this one?

Thanks again for the help and time.

Kind Regards

Mark

On Tue, Jan 5, 2021 at 2:18 PM Thomas Markwalder <[hidden email]> wrote:

Hi:

The reason is works for me is that my client is DHCP client.  This my
server output:

"
:
Listening on LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   Socket/fallback/fallback-net
Server starting service.
Devboot
DHCPDISCOVER from 08:00:27:25:d3:f4 via enp0s10
DHCPOFFER on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
Devboot
DHCPREQUEST for 178.16.1.100 (178.16.1.30) from 08:00:27:25:d3:f4 via
enp0s10
DHCPACK on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
"

Your's appears to be a BOOTP client.  BOOTP packets do not go through
classification.



_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Markwalder]

Hi Mark:

Sorry, you are out of luck.  BOOTP packets cannot be pushed through classification.  They actually go through their own handler logic (server/bootp.c) and it does not invoke the classify_client() function, and even if it did it does not go through other critical points where classification has an impact.

Regards,

Thomas

On 1/5/21 9:31 AM, Mark Mc Nicholas wrote:

Thank you Thomas for the clarification,

I've just finished testing with a DHCP client when I saw your mail come in and my results match. So is it possible to get BOOTP packets to go through classification or am I outta luck on this one?

Thanks again for the help and time.

Kind Regards

Mark

On Tue, Jan 5, 2021 at 2:18 PM Thomas Markwalder <[hidden email]> wrote:

Hi:

The reason is works for me is that my client is DHCP client.  This my
server output:

"
:
Listening on LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   LPF/enp0s10/08:00:27:c7:c6:20/178.16.1.0/24
Sending on   Socket/fallback/fallback-net
Server starting service.
Devboot
DHCPDISCOVER from 08:00:27:25:d3:f4 via enp0s10
DHCPOFFER on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
Devboot
DHCPREQUEST for 178.16.1.100 (178.16.1.30) from 08:00:27:25:d3:f4 via
enp0s10
DHCPACK on 178.16.1.100 to 08:00:27:25:d3:f4 via enp0s10
"

Your's appears to be a BOOTP client.  BOOTP packets do not go through
classification.



_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Pat Dery]

Hi

you could activate log debug to see the content of the data you are
trying to match

for example I used this to see the models than was able to match the
correct data

log(info, concat("debug: mac= ", binary-to-ascii(16, 8,":", option
dhcp-client-identifier)," modnum= ",option SA.modnum," devtype= ",option
SA.devtype ," swver= ",option SA.swver));

adjust for your needs

Patrick

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Hi Patrick,

Thanks for the suggestion however Thomas has confirmed the issue is that BOOTP packets don't go through classification.

@Thomas & Simon thank you both also for taking the time to help and share your knowledge

Cheers

Mark

On Tue, Jan 5, 2021 at 2:50 PM Patrick Fortin <[hidden email]> wrote:

Hi

you could activate log debug to see the content of the data you are
trying to match

for example I used this to see the models than was able to match the
correct data

log(info, concat("debug: mac= ", binary-to-ascii(16, 8,":", option
dhcp-client-identifier)," modnum= ",option SA.modnum," devtype= ",option
SA.devtype ," swver= ",option SA.swver));

adjust for your needs

Patrick

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Mark Mc Nicholas <[hidden email]> wrote:

> Thanks for the suggestion however Thomas has confirmed the issue is that BOOTP packets don't go through classification.

Bootp is still around ?

Are these the only devices that will use bootp ? If so, then one work around would be to give them their own pool (where you can set next-server) and deny bootp for all other pools.

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Markwalder]

Good point, Simon.  One can allow/deny bootp so they could be isolated
to their own pool.

On 1/5/21 11:58 AM, Simon Hobson wrote:

> Mark Mc Nicholas <[hidden email]> wrote:
>
>> Thanks for the suggestion however Thomas has confirmed the issue is that BOOTP packets don't go through classification.
> Bootp is still around ?
>
> Are these the only devices that will use bootp ? If so, then one work around would be to give them their own pool (where you can set next-server) and deny bootp for all other pools.
>
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mark Mc Nicholas]

Thank you Simon,

That solution solves the problem for me also :)

Cheers

Mark

On Tue, Jan 5, 2021 at 5:01 PM Thomas Markwalder <[hidden email]> wrote:

Good point, Simon.  One can allow/deny bootp so they could be isolated
to their own pool.

On 1/5/21 11:58 AM, Simon Hobson wrote:
> Mark Mc Nicholas <[hidden email]> wrote:
>
>> Thanks for the suggestion however Thomas has confirmed the issue is that BOOTP packets don't go through classification.
> Bootp is still around ?
>
> Are these the only devices that will use bootp ? If so, then one work around would be to give them their own pool (where you can set next-server) and deny bootp for all other pools.
>
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users