how to set class attributes for a host or group instead of a pool?

Glenn Satchell glenn.satchell at
Thu Nov 7 06:25:40 UTC 2013

Your example below will work fine (as long as the syntax is ok). A
fixed-address host can still be a member of a class and obtain all the
class attributes.

The allow/deny bit does not allow or deny the attributes of the class,
rather it allows or denies access to a pool based on membership of the

So, in your case *if* the host is booted as PXE it will have the
vendor-class-identifier set to PXEClient and so be a member of the
pxeclients class, and therefore have those class attributes (next-server,
etc) added to it. It gets its IP address in the same fixed-address way as
normal and everything should be fine.

If it is booted normally, then it doesn't have the vendor-class-identifier
set to PXEClient and so it won't be a member of that class and won't have
those attributes (next-server, etc) set.

If the above doesn't work for you, then put a group {} statement around
the host statements and add something like this in the group. You can make
the if statement as complex as you need to.

group {
if substring(option vendor-class-identifier, 0, 9) = "PXEClient" {
      next-server <tftp server>;
      filename "pxelinux.0";
host ... { ... }
host ... { ... }


On Thu, November 7, 2013 2:54 am, Steve Rikli wrote:
> Our DHCP is composed of groups of known hosts in multiple subnets,
> with fixed-address assignments based on hardware ethernet addresses.
> I'd like to use functionality similar to this typical example:
>   class "pxeclients" {
>      match if substring(option vendor-class-identifier, 0, 9) =
> "PXEClient";
>      next-server <tftp server>;
>      filename "pxelinux.0";
>   }
> with allow/deny as needed; but it seems that global class can only be
> applied to pools with ranges, rather than a host or group of hosts.
> So today to enable pxebooting we usually add next-server & filename to a
> host{} (e.g. for a re-install situation) or to a group{} (e.g. when
> bringing up a new subnet or installing a new batch of clients, etc.).
> This works well enough, but gets cumbersome.
> Recently, we've added a new batch of hosts with UEFI as well as a legacy
> BIOS mode, so we're likely to need something more complex, e.g.:
>   match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
>      next-server <tftp server>;
>      if option arch = 00:06 {
>        filename "bootia32.efi";
>        }
>      else if option arch = 00:07 {
>        filename "bootx64.efi";
>        }
>      else {
>        filename "pxelinux.0";
>      }
> which seems unwieldy to replicate in groups and individual hosts.
> Is there a more elegant way to define a global "class"-like function,
> potentially with multiple matches and if-then conditions, yet still be
> able to selectively enable/disable it for given groups and individual
> hosts, without replicating the whole block of code everywhere?
> Cheers,
> sr.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at

More information about the dhcp-users mailing list