Declaring subclasses on a per-subnet basis
Glenn Satchell
glenn.satchell at uniq.com.au
Fri Aug 10 02:32:12 UTC 2012
Yes, both of those should work. The "if" construct can be used in any
scope (global, subnet, pool, group, class, and so on).
One feature that is not available is to set an option in the global scope,
and be able to unset it in other scopes. So you need set the options in
all appropriate scopes.
regards,
-glenn
On Fri, August 10, 2012 3:49 am, Hristov, Tihomir H. wrote:
>
> That is great,
>
> So based on what you are informing me, the following should work:
>
> group {
> if option vendor-class-identifier ~= 'AAPLBSDPC' {
> option root-path "nfs:192.168.1.1:/nbi:NetInstall-Restore.dmg";
> } else {
> option root-path "nfs:192.168.1.2:/windows:Windows.iso"
> }
> subnet 10.10.0.0 netmask 255.255.0.0 {
> ...
> }
> subnet 10.11.0.0 netmask 255.255.0.0 {
> ...
> }
> }
>
> (* I am using root-path as just an example, in production I am setting
> totally different options)
>
>
> Again, I have a small question. If I was not to use a group, would the
> following config work as expected and set the two different values for
> option root-path based on the vendor-class-identifier?
>
>
> subnet 10.10.0.0 netmask 255.255.0.0 {
> if option vendor-class-identifier ~= 'AAPLBSDPC' {
> option root-path "nfs:192.168.1.1:/nbi:NetInstall-Restore.dmg";
> } else {
> option root-path "nfs:192.168.1.2:/windows:Windows.iso"
> }
> }
>
> Thank you very much
>
>
> -----Original Message-----
> From: dhcp-users-bounces+thristov=odu.edu at lists.isc.org
> [mailto:dhcp-users-bounces+thristov=odu.edu at lists.isc.org] On Behalf Of
> Glenn Satchell
> Sent: Thursday, August 09, 2012 9:36 AM
> To: Users of ISC DHCP
> Subject: RE: Declaring subclasses on a per-subnet basis
>
> You could use the "if" statement, see the dhcp-eval man page. There are
> some examples matching options. You can use '=' for straight equals, or
> '~=' for regex matches.
>
> Inside the group you could have something like this. I'm not sure those
> are the right strings for each vendor...
>
> if option vendor-class-identifier ~= 'MSFT' {
> ...
> } else if option vendor-class-identifier ~= 'MACOS' {
> ...
> } else {
> # anything else
> ...
> }
>
> regards,
> -glenn
>
> On Thu, August 9, 2012 10:13 pm, Hristov, Tihomir H. wrote:
>> 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: dhcp-users-bounces+thristov=odu.edu at lists.isc.org
>> [mailto:dhcp-users-bounces+thristov=odu.edu at lists.isc.org] 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:192.168.1.1:/nbi:NetInstall-Restore.dmg";
>>
>> subnet 10.10.0.0 netmask 255.255.0.0 {
>> ...
>> }
>> subnet 10.11.0.0 netmask 255.255.0.0 {
>> ...
>> }
>> }
>> 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.
>>
>> regards,
>> -glenn
>>
>> 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
>>> (https://lists.isc.org/pipermail/dhcp-users/2012-June/015558.html) 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 10.10.0.0 netmask 255.255.0.0 {
>>>
>>> subclass "vendor-class" "AAPLBSDPC" {
>>> option root-path "nfs:192.168.1.1:/nbi:NetInstall-Restore.dmg";
>>> }
>>> pool {
>>> option routers 10.10.1.1;
>>> option domain-name-servers 10.101.21;
>>> range 10.10.7.1 10.10.7.254;
>>> 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 10.10.0.0 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:192.168.1.1:/nbi:NetInstall-Restore.dmg" 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= 10.10.10.1)
>>>
>>> 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 lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>> --
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 692430684) is spam:
> Spam:
> https://www.spamtrap.odu.edu/b.php?i=692430684&m=1b6f108147f2&t=20120809&c=s
> Not spam:
> https://www.spamtrap.odu.edu/b.php?i=692430684&m=1b6f108147f2&t=20120809&c=n
> Forget vote:
> https://www.spamtrap.odu.edu/b.php?i=692430684&m=1b6f108147f2&t=20120809&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
More information about the dhcp-users
mailing list