Declaring subclasses on a per-subnet basis

Hristov, Tihomir H. thristov at
Thu Aug 9 12:13:47 UTC 2012

Thanks for the quick response guys,

I do like the group{} functionality and can definitely use it for our special lab subnets. This still does not solve our problem completely. In our case, we would still need to do some kind of matching on the vendor-class-identifier. Reason being that one those subnets we have both Windows and MAC clients. Based on the vendor-class-identifier MACs would be getting special options set, while Windows would be using something totally different. How would we incorporate a filter/matching statement inside the group?

Thank you

-----Original Message-----
From: at [ at] On Behalf Of Glenn Satchell
Sent: Thursday, August 09, 2012 1:51 AM
To: Users of ISC DHCP
Subject: Re: Declaring subclasses on a per-subnet basis

Hi Tihomir

If the option is only required for specific subnets, then perhaps the group{} functionality would work better, for example:

group {
    option root-path "nfs:";

    subnet netmask {
    subnet netmask {
Or if it is only to be valid in a single subnet you could set the option in that subnet or pool only.

Classes are more useful for globally matching a subset of hosts based on some other parameter other than subnet.


On Thu, August 9, 2012 12:36 pm, Hristov, Tihomir H. wrote:
>   Dear all,
>  I an a Network engineer for Old Dominion University, Norfolk, 
> Virginia and my team is looking into a future PXE configuration. We 
> are trying to define classes with special options and have them 
> applicable only to some special "lab" subnets of the environment.
>  Based on research done so far, we have seen that classes and 
> subclasses are parsed on a global level and thus would apply to all 
> clients, and just the special "lab" subnets.
>  Still in a post from June 2012
> ( we 
> see an interesting configuration. Using it as an example, the 
> configuration we have in mind would match on a substring of 
> vendor-class-identifier (value AAPLBSDPC in this case) and set the root-path option (an example).
> It would look like this:
> class "vendor-class" {
> 		match substring(option vendor-class-identifier,0,9); }
> subnet netmask {
>   subclass "vendor-class" "AAPLBSDPC"  {
>      option root-path "nfs:";
>   }
>   pool {
> 		option routers;
> 		option domain-name-servers 10.101.21;
> 		range;
> 		option domain-name-servers 10.101.21;
>   }
> }
>  The main question here is:
>   1. Would this configuration work as we would like and the class 
> declaration would affect only clients in the subnet?
>   2. Or would the ISC DHCP parser end up treating the subclass as a 
> global declaration and thus set option root-path to 
> "nfs:" for all clients, 
> regardless of their subnet?
> In case this would end up a global configuration, we were thinking of 
> declaring a class that matches on 2 conditions.
>  1. vendor-class-identifier substring
>  2. giaddress
>  Since we use DHCP Relay Agents all over our network, we would be able 
> to use the giaddress and match it to the special "lab" subnets. We 
> have seen some references to
>    match if (option dhcp-giaddress-field=
>  and we were wondering if that would work. If not, what is the way to 
> check the Relay Agent IP Address?
>  Your help and guidance would be greatly appreciated.
>  Sincerely,
>  Tihomir Hristov
>  Senior Network Engineer
>  Old Dominion University
>  Office of Computing and Communications Services
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at

dhcp-users mailing list
dhcp-users at


Teach CanIt if this mail (ID 692326909) is spam:
Not spam:
Forget vote:

More information about the dhcp-users mailing list