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