I am having trouble relocating and upgrading a number of dhcp servers. I am upgrading from solaris running dhcpd 3.0.4 to centos 7's dhcp 4.2.5-77.
The problem: when I test the config on the new dhcp servers, I get the following error: "No free leases".
As I am still testing, I have not copied the leases thus it is not clear why there would be no free leases.
As I have no lab equipment to test against, I am generating similar queries using the dhtest tool. I started with a packet capture on the live dhcp servers and constructed a dhcp discovery packet based on it. I have also started small, with the smallest configuration possible that should still work.
The queries originate from DSL customer premises equipment (CPE), and are forwarded by a dsl shelf manager. The relevant fields in the forwarded queries are as follows:
giaddr: <management ip of dsl shelf> (Please note this is NOT the ip address facing the CPE)
chaddr: <mac of CPE>
option 82.1: circuit id
option 82.2: remote id
option 60: vendor class identifier (only on boot and management classes)
The current live system is running 8 pairs of dhcp servers in different regions. They have been successfully running for more than 8 years. At last count there are about 440,000 active leases.
I am attempting to build a pair of centrally located servers. I am not trying to do HA yet.
I am including a sanitized dhcpd.conf file for you to look at.
Thank you all for your time!
--jason
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
Re: migrate from remotely located to central servers
So, the DISCOVER is not matching any of your classes. Define
another pool to issue
leases from that doesn't match any class: pool { deny members of "RegionX-RGMGMT-CPE-MODELx";
deny members of "RegionX-BOOT-CPE-MODELx";
deny members of "RegionX-INET";
deny dynamic bootp clients; authoritative; range 192.168.xxx.2 192.168.xxx.15; }
This should issue a lease and trigger your 'on commit' log
statement.
Bill
On 7/29/2020 12:35 PM, Jason Brooks
wrote:
Hello,
I am having trouble relocating and upgrading a number of
dhcp servers. I am upgrading from solaris running dhcpd 3.0.4
to centos 7's dhcp 4.2.5-77.
The problem: when I test the config on the new dhcp
servers, I get the following error: "No free leases".
As I am still testing, I have not copied the leases thus it
is not clear why there would be no free leases.
As I have no lab equipment to test against, I am
generating similar queries using the dhtest tool. I started with a
packet capture on the live dhcp servers and constructed a dhcp
discovery packet based on it. I have also started small, with
the smallest configuration possible that should still work.
The queries originate from DSL customer premises equipment
(CPE), and are forwarded by a dsl shelf manager. The
relevant fields in the forwarded queries are as follows:
giaddr: <management ip of dsl shelf> (Please note
this is NOT the ip address facing the CPE)
chaddr: <mac of CPE>
option 82.1: circuit id
option 82.2: remote id
option 60: vendor class identifier (only on boot and
management classes)
The current live system is running 8 pairs of dhcp servers
in different regions. They have been successfully running for
more than 8 years. At last count there are about 440,000
active leases.
I am attempting to build a pair of centrally located
servers. I am not trying to do HA yet.
I am including a sanitized dhcpd.conf file for you to look
at.
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
Re: migrate from remotely located to central servers
Hello Bill,
At first I didn't understand, but now I do. Once I defined the pool denying class members, I was able to get ip addresses in the 192.168.188.range. Thanks!
I began to run "dhcpd -d" and playing with the log output to see if my substring statements were even making sense.
So with the circuit id substring statements, I wasn't comparing correctly. It's not clear why 3.0.4 worked this way. I needed the two bytes on the far right side of the circuit id...thus
note the use of suffix rather than substring and the lack of "\x" inside the double quotes.
So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned. Whereas the boot filename is. Why not? Based on what I found 'tftp-server-name" should correspond to dhcp option 66: defined in rfc2132.
I have noticed that it's hard to figure out which isc dhcpd options map to those defined in the rfcs. I found THIS table, which helps. Is there a cross-reference like this in the isc dhcpd docs somewhere?
Enclosed is my updated, sanitized dhcpd.conf file with your suggested alterations and a few more of my own.
Thank you thus far for your time!
--jason
On Wed, Jul 29, 2020 at 11:51 AM Bill Shirley <[hidden email]> wrote:
So, the DISCOVER is not matching any of your classes. Define
another pool to issue
leases from that doesn't match any class: pool { deny members of "RegionX-RGMGMT-CPE-MODELx";
deny members of "RegionX-BOOT-CPE-MODELx";
deny members of "RegionX-INET";
deny dynamic bootp clients; authoritative; range 192.168.xxx.2 192.168.xxx.15; }
This should issue a lease and trigger your 'on commit' log
statement.
Bill
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned. Whereas the boot filename is. Why not?
Have you checked the option request list sent by the client ? By default, the server will only return options the client asks for.
Simon
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
Looks like your domain-name-servers option is incorrect: option domain-name-servers 8.8.8.8, 8.8.4.4;
Add this to your log statement to see the options requested: " ReqOpt:",
pick-first-value(binary-to-ascii(10, 8, ",", option
dhcp-parameter-request-list), "(none)"), Make sure the client is requesting option 66. BTW,
if the dhcpd encounters a null
in the log text, it will truncate the rest of the line. That's
why I use 'pick-first-value' a lot.
If it's not requesting option 66, you might try forcing the
option. I've never used this: if exists dhcp-parameter-request-list { # Always send the local-pac-server (252) option
(specified in hexadecimal, ie: 252 = 0xfc) option dhcp-parameter-request-list = concat(option
dhcp-parameter-request-list, fc); }
I have used this to replace the entire requested option list: option dhcp-parameter-request-list = 01:
03: 06: 0c: 0f: 1c: 2a;
Bill
On 7/29/2020 7:45 PM, Jason Brooks
wrote:
Hello Bill,
At first I didn't understand, but now I do. Once I defined
the pool denying class members, I was able to get ip addresses
in the 192.168.188.range. Thanks!
I began to run "dhcpd -d" and playing with the log output
to see if my substring statements were even making sense.
So with the circuit id substring statements, I wasn't
comparing correctly. It's not clear why 3.0.4 worked this
way. I needed the two bytes on the far right side of the
circuit id...thus
note the use of suffix rather than substring and the lack
of "\x" inside the double quotes.
So my next issue here is in the RegionX-BOOT-CPE-MODELx
class declaration, tftp-server-name is not being returned.
Whereas the boot filename is. Why not? Based on what I found
'tftp-server-name" should correspond to dhcp option 66:
defined in rfc2132.
I have noticed that it's hard to figure out which isc dhcpd
options map to those defined in the rfcs. I found THIS table, which helps. Is
there a cross-reference like this in the isc dhcpd docs
somewhere?
Enclosed is my updated, sanitized dhcpd.conf file with your
suggested alterations and a few more of my own.
Thank you thus far for your time!
--jason
On Wed, Jul 29, 2020 at
11:51 AM Bill Shirley <[hidden email]>
wrote:
So, the DISCOVER is not matching any of your classes.
Define another pool to issue
leases from that doesn't match any class: pool { deny members of
"RegionX-RGMGMT-CPE-MODELx"; deny members of
"RegionX-BOOT-CPE-MODELx"; deny members of "RegionX-INET";
deny dynamic bootp
clients; authoritative; range 192.168.xxx.2 192.168.xxx.15; }
This should issue a lease and trigger your 'on commit'
log statement.
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned. Whereas the boot filename is. Why not?
Have you checked the option request list sent by the client ? By default, the server will only return options the client asks for.
Simon
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
I will sit down and re-read the man pages: thank you for the reminder.
good to know about the dns servers.
and thanks or the log statement suggestions.
A note from Simon Hobson had me understand that the client must ask for the information, so I am going to re-construct my test query to see if the tftp information comes back. But thanks for the suggestions to force options.
--jason
On Thu, Jul 30, 2020 at 6:51 AM Bill Shirley <[hidden email]> wrote:
Looks like your domain-name-servers option is incorrect: option domain-name-servers 8.8.8.8, 8.8.4.4;
Add this to your log statement to see the options requested: " ReqOpt:",
pick-first-value(binary-to-ascii(10, 8, ",", option
dhcp-parameter-request-list), "(none)"), Make sure the client is requesting option 66. BTW,
if the dhcpd encounters a null
in the log text, it will truncate the rest of the line. That's
why I use 'pick-first-value' a lot.
If it's not requesting option 66, you might try forcing the
option. I've never used this: if exists dhcp-parameter-request-list { # Always send the local-pac-server (252) option
(specified in hexadecimal, ie: 252 = 0xfc) option dhcp-parameter-request-list = concat(option
dhcp-parameter-request-list, fc); }
I have used this to replace the entire requested option list: option dhcp-parameter-request-list = 01:
03: 06: 0c: 0f: 1c: 2a;
Bill
On 7/29/2020 7:45 PM, Jason Brooks
wrote:
Hello Bill,
At first I didn't understand, but now I do. Once I defined
the pool denying class members, I was able to get ip addresses
in the 192.168.188.range. Thanks!
I began to run "dhcpd -d" and playing with the log output
to see if my substring statements were even making sense.
So with the circuit id substring statements, I wasn't
comparing correctly. It's not clear why 3.0.4 worked this
way. I needed the two bytes on the far right side of the
circuit id...thus
note the use of suffix rather than substring and the lack
of "\x" inside the double quotes.
So my next issue here is in the RegionX-BOOT-CPE-MODELx
class declaration, tftp-server-name is not being returned.
Whereas the boot filename is. Why not? Based on what I found
'tftp-server-name" should correspond to dhcp option 66:
defined in rfc2132.
I have noticed that it's hard to figure out which isc dhcpd
options map to those defined in the rfcs. I found THIS table, which helps. Is
there a cross-reference like this in the isc dhcpd docs
somewhere?
Enclosed is my updated, sanitized dhcpd.conf file with your
suggested alterations and a few more of my own.
Thank you thus far for your time!
--jason
On Wed, Jul 29, 2020 at
11:51 AM Bill Shirley <[hidden email]>
wrote:
So, the DISCOVER is not matching any of your classes.
Define another pool to issue
leases from that doesn't match any class: pool { deny members of
"RegionX-RGMGMT-CPE-MODELx"; deny members of
"RegionX-BOOT-CPE-MODELx"; deny members of "RegionX-INET";
deny dynamic bootp
clients; authoritative; range 192.168.xxx.2 192.168.xxx.15; }
This should issue a lease and trigger your 'on commit'
log statement.
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.