No Option 43 in DHCP ACK

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

No Option 43 in DHCP ACK

Jason Bailey
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.

Jason

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Steven Carr
On 13 July 2015 at 19:42, Jason Bailey <[hidden email]> wrote:
> 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))

AFAIK you still need a class, otherwise it's not going to match and
send the custom option space back to the client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Maarten Carels
In reply to this post by Jason Bailey
> On 13 Jul 2015, at 20:42 , Jason Bailey <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

signature.asc (538 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Jason Bailey
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 [hidden email] 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Peter Rathlev
On Wed, 2015-07-15 at 10:55 -0600, Jason Bailey wrote:

> 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.

Classes are always global. It's an error to place the class declaration
inside e.g. a subnet declaration.

> 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.

Could you maybe use something like this:

  option X-CALIX-Selector code 247 = string;
  subnet 192.0.2.0 netmask 255.255.255.128 {
      option X-CALIX-Selector "asdf";
  }
  subnet 192.0.2.128 netmask 255.255.255.128 {
      # No CALIX option
  }
  subnet 203.0.113.0 netmask 255.255.255.0 {
      option X-CALIX-Selector "something-else";
  }
  class "CALIX-ONT" {
      match if substring(option vendor-class-identifier, 0, 9) = "Calix ONT";
      vendor-option-space CALIX-ONT-SERVER;
      if (config-option X-CALIX-Selector = "asdf") {
            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";
      } elsif (config-option X-CALIX-Selector = "something-else") {
            option CALIX-ONT-SERVER.cms-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.syslog-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.firmware1 "another-blah";
      }
  }

Blocks without an X-CALIX-Selector config-option shouldn't hand you any
of the options.

--
Peter



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

RE: No Option 43 in DHCP ACK

Frank Bulk
Jason,

I do it within the subnet (we're also a Calix shop) and it seems to work
fine.

Frank

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Peter Rathlev
Sent: Saturday, July 18, 2015 8:38 AM
To: Users of ISC DHCP <[hidden email]>
Subject: Re: No Option 43 in DHCP ACK

On Wed, 2015-07-15 at 10:55 -0600, Jason Bailey wrote:

> 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.

Classes are always global. It's an error to place the class declaration
inside e.g. a subnet declaration.

> 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.

Could you maybe use something like this:

  option X-CALIX-Selector code 247 = string;
  subnet 192.0.2.0 netmask 255.255.255.128 {
      option X-CALIX-Selector "asdf";
  }
  subnet 192.0.2.128 netmask 255.255.255.128 {
      # No CALIX option
  }
  subnet 203.0.113.0 netmask 255.255.255.0 {
      option X-CALIX-Selector "something-else";
  }
  class "CALIX-ONT" {
      match if substring(option vendor-class-identifier, 0, 9) = "Calix
ONT";
      vendor-option-space CALIX-ONT-SERVER;
      if (config-option X-CALIX-Selector = "asdf") {
            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";
      } elsif (config-option X-CALIX-Selector = "something-else") {
            option CALIX-ONT-SERVER.cms-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.syslog-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.firmware1 "another-blah";
      }
  }

Blocks without an X-CALIX-Selector config-option shouldn't hand you any
of the options.

--
Peter



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Jason Bailey
Thank you all for the many options. I'm still evaluating the approach I'd like to take.

I do have another question, however. Is it possible to match class based on option 43 data found in the client's DHCP request? Could I do a substring match of sorts against that data?

Best,

Jason

On 08/01/2015 07:36 PM, Frank Bulk wrote:
Jason,

I do it within the subnet (we're also a Calix shop) and it seems to work
fine.

Frank

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Peter Rathlev
Sent: Saturday, July 18, 2015 8:38 AM
To: Users of ISC DHCP [hidden email]
Subject: Re: No Option 43 in DHCP ACK

On Wed, 2015-07-15 at 10:55 -0600, Jason Bailey wrote:
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.
Classes are always global. It's an error to place the class declaration
inside e.g. a subnet declaration.

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.
Could you maybe use something like this:

  option X-CALIX-Selector code 247 = string;
  subnet 192.0.2.0 netmask 255.255.255.128 {
      option X-CALIX-Selector "asdf";
  }
  subnet 192.0.2.128 netmask 255.255.255.128 {
      # No CALIX option
  }
  subnet 203.0.113.0 netmask 255.255.255.0 {
      option X-CALIX-Selector "something-else";
  }
  class "CALIX-ONT" {
      match if substring(option vendor-class-identifier, 0, 9) = "Calix
ONT";
      vendor-option-space CALIX-ONT-SERVER;
      if (config-option X-CALIX-Selector = "asdf") {
            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";
      } elsif (config-option X-CALIX-Selector = "something-else") {
            option CALIX-ONT-SERVER.cms-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.syslog-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.firmware1 "another-blah";
      }
  }

Blocks without an X-CALIX-Selector config-option shouldn't hand you any
of the options.



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: No Option 43 in DHCP ACK

Jason Bailey
So I've managed to make several of the suggested configurations work with newer versions of the DHCP server (CentOS 7, for example), but I cannot get it to work with the version we are running (CentOS 6, ISC DHCP 4.1.1). Any ideas as to why that might be?

Jason



On 08/04/2015 02:45 PM, Jason Bailey wrote:
Thank you all for the many options. I'm still evaluating the approach I'd like to take.

I do have another question, however. Is it possible to match class based on option 43 data found in the client's DHCP request? Could I do a substring match of sorts against that data?

Best,

Jason

On 08/01/2015 07:36 PM, Frank Bulk wrote:
Jason,

I do it within the subnet (we're also a Calix shop) and it seems to work
fine.

Frank

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Peter Rathlev
Sent: Saturday, July 18, 2015 8:38 AM
To: Users of ISC DHCP [hidden email]
Subject: Re: No Option 43 in DHCP ACK

On Wed, 2015-07-15 at 10:55 -0600, Jason Bailey wrote:
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.
Classes are always global. It's an error to place the class declaration
inside e.g. a subnet declaration.

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.
Could you maybe use something like this:

  option X-CALIX-Selector code 247 = string;
  subnet 192.0.2.0 netmask 255.255.255.128 {
      option X-CALIX-Selector "asdf";
  }
  subnet 192.0.2.128 netmask 255.255.255.128 {
      # No CALIX option
  }
  subnet 203.0.113.0 netmask 255.255.255.0 {
      option X-CALIX-Selector "something-else";
  }
  class "CALIX-ONT" {
      match if substring(option vendor-class-identifier, 0, 9) = "Calix
ONT";
      vendor-option-space CALIX-ONT-SERVER;
      if (config-option X-CALIX-Selector = "asdf") {
            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";
      } elsif (config-option X-CALIX-Selector = "something-else") {
            option CALIX-ONT-SERVER.cms-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.syslog-address yy.yy.yy.yy;
            option CALIX-ONT-SERVER.firmware1 "another-blah";
      }
  }

Blocks without an X-CALIX-Selector config-option shouldn't hand you any
of the options.




_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users