No Option 43 in DHCP ACK

Jason Bailey jbailey at emerytelcom.com
Wed Jul 15 16:55:56 UTC 2015


Calix ONTs, actually. I'm trying to get only certain ONTs to pick up 
certain option 43 configuration directives.

Their documentation says:

Configure the default global DHCP options at the DHCP server as follows:
option space CALIX-ONT-SERVER;
option CALIX-ONT-SERVER.cms-address code 1 = ip-address;
option CALIX-ONT-SERVER.second-tftp-address code 2 = ip-address;
option CALIX-ONT-SERVER.syslog-address code 4 = ip-address;
option CALIX-ONT-SERVER.firmware1 code 101 = text;
option CALIX-ONT-SERVER.firmware2 code 102 = text;
option CALIX-ONT-SERVER.firmware3 code 103 = text;

Configure specific values for DHCP options within a subnet declaration, 
as shown in the following example:

# AE-ONT Management Network
subnet xxx.xxx.xxx.x netmask xxx.xxx.xxx.x{
vendor-option-space CALIX-ONT-SERVER;
option CALIX-ONT-SERVER.cms-address xxx.xxx.xxx.xxx;
option CALIX-ONT-SERVER.syslog-address xxx.xxx.xxx.xxx;
option CALIX-ONT-SERVER.firmware1 "blah";

The problem is, that doesn't work (I couldn't get to work, anyhow). If 
you use class matching, the DHCP server will send option 43 information, 
but unfortunately (as far as I see it, anyway), only if those classes 
are declared globally. The problem with that is that the matching ends 
up being all encompassing and ONTs end up getting options that they 
shouldn't. In short, it creates severe issues on the network.

If I could do class matching per subnet (i.e. at the subnet level), that 
would fix my problems. I just don't see how to do that.

Jason


On 07/14/2015 01:56 AM, Maarten Carels wrote:
>> On 13 Jul 2015, at 20:42 , Jason Bailey <jbailey at emerytelcom.com> wrote:
>>
>> Hi all,
>>
>> I'm trying to troubleshoot a problem with DHCP option 43. I've defined the vendor option space and declared the vendor specific options per the vendor's documentation, but I'm not getting any results.
>>
>> The device (DHCP client) is sending options 53 (request), 60 (vendor class ident), 61 (client identifier), 43 (vendor specific info) , 55 (parameter request list), among a few others. Option 55 includes 43 (vendor specific info) in addition to the usual items (like subnet mask, router, etc). The server is sending an ACK, but it doesn't include any of the option 43 items I've defined.
>>
>> In my DHCP server config, I've defined "option space XYZ" and "option XYZ.item code 1 = ip address". I've also configured defined "vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the subnet declaration (the entire subnet has been created entirely for the same type of devices, so there's no need to match only a certain type of devices (i.e. device class))
>>
>> dhcpd -t doesn't complain about any issues in my config file, and there are no issues in the log (I'm using 'log-facility local7').
>>
>> I'm at a loss at the moment, so any help is greatly appreciated. I'm running ISC DHCP 4.1.1 on CentOS 6.6.
> I guess this is for the cisco wireless stuff.
> I use this:
> option space Cisco_LWAPP_AP;
> option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
>
>
> subnet 192.168.31.96 netmask 255.255.255.224 {
> 	option routers 192.168.31.97;
> 	vendor-option-space Cisco_LWAPP_AP;
> 	option Cisco_LWAPP_AP.server-address 192.168.31.250;
>
> 	pool {
> 		failover peer "kantoor-draadloos";
>
> 		# most fixed
> 		range 192.168.31.118 192.168.31.119;
> 	}
> }
>
> Works for me (Internet Systems Consortium DHCP Server 4.3.1 on Debian 7.8)
>
> —maarten
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

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


More information about the dhcp-users mailing list