I'm facing a problem trying to define and use two different option
spaces. For some reason only the last defined option space actually
works. Swapping them makes the other work.
We're running isc-dhcpd-4.3.2 (vanilla from source) on CentOS 5+6 in a
text-book failover configuration.
The option space configuration that I can't get to work is:
option space Cisco-WLC;
option Cisco-WLC.ControllerIP code 241 = ip-address;
option Cisco-WLC-encapsulation code 43 = encapsulate Cisco-WLC;
option space ASCOM;
option ASCOM.servicediscovery code 10 = text;
option ASCOM-encapsulation code 43 = encapsulate ASCOM;
class "Ascom-TeleCARE-IP" {
match if option vendor-class-identifier = "1.3.6.1.4.1.27614.1.2";
vendor-option-space ASCOM;
option ASCOM.servicediscovery "192.0.2.50/RoomControllerDH";
}
class "Cisco-WLC" {
match if substring(option vendor-class-identifier, 0, 8) = "Cisco AP";
log(info, "inside Cisco-WLC class");
vendor-option-space Cisco-WLC;
option Cisco-WLC.ControllerIP 198.51.100.20;
}
Apart from this there's of course the subnet definitions et cetera.
Both of these options spaces / vendor encapsulations work by themselves
with no problems. But if both are defined (as shown above) then only the
last "option space" defined (the ASCOM one above) works.
Traffic captures verifies that the clients (Cisco 2700 AP and Ascom
teleCARE IP) are sending what they should. Logging statements inside the
"Cisco-WLC" class actually fires, but for some reason dhcpd doesn't send
the option to the client, also verified with tcpdump.
Shouldn't I be able to have multiple option spaces in this way?
Or current work-around is to send the Cisco options as an opaque blob:
option vendor-encapsulated-options F1:04:C6:33:64:14;
This works but is rather unelegant. And some day we might have a third
or fourth system that expects vendor encapsulated options that are much
less straightforward than the Cisco-WLC example.
Thanks a bunch for your time! :-)
--
Peter