Change in handling of multiple names for the same option number in dhcpd 3.0.x vs 3.1.x and later

Peter Norton spacey+dhcp-isc.org at lenin.net
Tue Nov 11 22:31:01 UTC 2008


Greetings,

I have a situation that is probably not unique to my company. In our
enterprise, we have Solaris x86 and Linux systems that boot using grub, and
via the magic dhcp option 150.  We also have a Cisco Call Manager phone
infrastructure deployed company-wide, on their own networks that rely on
option 150 being defined differently.

Using ISC dhcpd version 3.0.x (specifically, version 3.0pl2, and 3.0.7), the
following works:

option call-manager-addr code 150 = array of ip-address;
option grubmenu code 150 = text;

By defining two options we can deploy two variations on option 150. For
hosts to be jumpstarted, for example, we can create a jumpstart class for
them:

class "jumpstart-i386" {
    ...
    option grubmenu "/sun/boot/grub/menu.lst.HW200801";
}

and when this subclass is applied to a host option 150 is sent back as a
test string pointing to the menu.lst that we want to use for this build
(that is the HW200801 grub boot menu.

In the same configuration file, we can do this:

    subnet 10.0.8.128 netmask 255.255.255.128 {
           option routers 10.0.8.129
           option call-manager-addr 10.0.0.1, 10.0.1.1, 10.0.2.1;
           option subnet-mask 255.255.255.128;

        pool {
               range 10.0.8.139 10.0.8.254;
            failover peer "PHONE";
            deny dynamic bootp clients;
        }
    }

However, with the newer versions of dhcpd (tested with 3.1.1, 4.0.1b1, and
4.1.0b1), the definition of the grubmenu option seems to override the
definition of the call-manager-addr option, resulting in a parse failure.

I would like to ask two questions:

1) Is this an intentional change? Based on the overloading of the meaning of
option 150 in grub, etherboot, and Call Manager (though etherboot uses it as
a client->server option, and not as a server->client option) it seems clear
that there needs to be a way to deal with this conflict, even if it is on a
subnet-by-subnet or host-by-host basis. From the list of assigned tftp codes
at http://www.iana.org/assignments/bootp-dhcp-parameters/ it seems that
currently this situation is known, but not "resolved" in any sensible way
(eg. vendor-encapsulated options for grub).

2) Is there any way to vary the type and contents option 150 depending on
known info from the client, eg. the vendor-class-identifier, in versions
3.1.1 and above? Am I doomed to doing something like this:

option opt-150-hack code 150 = string;

subnet ...1 netmask ... { # phone network
 option opt-150-hack 0a:00:00:01:0a:00:01:01:0a:00:02:01; # Off the top of
my head attempt to encode 10.0.0.1,10.0.1.1,10.0.2.1
...
}

subnet ...2 netmask ... { # non-phone network
 option opt-150-hack "/sun/boot/grub/menu.lst.HW200801";
 # or would the above need to be the result of passing it through od -t x2
plus some colons?
 # option opt-150-hack
73:2f:6e:75:62:2f:6f:6f:2f:74:72:67:62:75:6d:2f:6e:65:2e:75:73:6c:2e:74:57:48:30:32:38:30:31:30:00:0a;
#Uggh?
}

Any insight, pointers, etc. would be appreciated. I haven't found a lot
directly related to my question or the change in the parser in the
documentation so far, and nothing about requiring a 1-to-1 mapping of
user-defined option names to option numbers.

Thanks,

-Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20081111/a6c741e6/attachment.html>


More information about the dhcp-users mailing list